login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2008
»
August
»
29
Re: [PATCH] x86: split e820 reserved entries record to late v4 - fix
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From: Yinghai Lu
Subject:
Re: [PATCH] x86: split e820 reserved entries record to late v4 - fix
Date: Friday, August 29, 2008 - 9:37 am
On Fri, Aug 29, 2008 at 9:05 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
quoted text
> > > On Fri, 29 Aug 2008, Yinghai Lu wrote: >> >> try to insert_resource second time, by expand the resource... > > I would hold off on this unless it's shown to actually be needed. And _if_ > it is needed, I would just make a new function for doing this all: > "insert_resource_expand_to_fit()" > > That said, I think the insert_resource()/__insert_resource() change is > pretty ok. However, it doesn't follow the rules, and is racy. The rules > for resources are: > > - the "internal" version (with the "__" prepended) is static to > resource.c, because it must not be called from outside, which is in > turn because: > > - it must be called with the lock taken by the caller, because otherwise > returning a "struct resource *" is racy - the resource is not protected > by anything! > > So the "insert_resource_expand_to_fit()" thing would look something like > this: > > void insert_resource_expand_to_fit(struct resource *root, struct resource *new) > { > write_lock(&resource_lock); > while (new->start && new->parent) { > struct resource *conflict; > > conflict = __insert_resource(root, new); > if (!conflict) > break; > if (conflict->start < new->start) > new->start = conflict->start; > if (conflict->end > new->end) > new->end = conflict->end; > } > write_unlock(&resource_lock); > } > > but the above is obviously _totally_ untested. >
good, will build one test stub to test it. YH --
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
[PATCH] x86: split e820 reserved entries record to late v4 ...
, Yinghai Lu
, (Fri Aug 29, 1:13 am)
Re: [PATCH] x86: split e820 reserved entries record to lat ...
, Yinghai Lu
, (Fri Aug 29, 1:18 am)
Re: [PATCH] x86: split e820 reserved entries record to lat ...
, Linus Torvalds
, (Fri Aug 29, 9:05 am)
Re: [PATCH] x86: split e820 reserved entries record to lat ...
, Yinghai Lu
, (Fri Aug 29, 9:37 am)
Re: [PATCH] x86: split e820 reserved entries record to lat ...
, Linus Torvalds
, (Fri Aug 29, 9:55 am)
Navigation
Create content
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Greg Kroah-Hartman
[PATCH 01/75] platform: prefix MODALIAS with "platform:"
stephane eranian
Re: perf_counters issue with PERF_SAMPLE_GROUP
Eric Sandeen
Re: [PATCH] xfs: do not pass unused params to xfs_flush_pages
Daniel Hazelton
Re: x86: 4kstacks default
Mathieu Desnoyers
Re: Linux 2.6.25-rc2
git
:
Johannes Schindelin
[PATCH] fetch: refuse to fetch into the current branch in a non-bare repository
Junio C Hamano
Re: [PATCH] http-push: making HTTP push more robust and more user-friendly
Oliver Kullmann
Re: how to move with history?
Alex Riesen
Re: git exclude patterns for directory
Andreas Ericsson
Re: why not TortoiseGit
linux-netdev
:
Andi Kleen
Re: RFC: Nagle latency tuning
Herbert Xu
Re: Oops in tun: bisected to Limit amount of queued packets per device
gregkh
Patch "IPv6: keep route for tentative address" has been added to the 2.6.34-stable...
Patrick McHardy
Re: [rfc 02/13] [RFC 02/13] netfilter: nf_conntrack_sip: Add callid parser
Krzysztof Oledzki
Re: Error: an inet prefix is expected rather than "0/0".
git-commits-head
:
Linux Kernel Mailing List
sh: Fix compile error by operands(mov.l) in sh3/entry.S
Linux Kernel Mailing List
New device ID for sc92031 [1088:2031]
Linux Kernel Mailing List
tmpfs: depend on shmem
Linux Kernel Mailing List
drivers/acpi: use kasprintf
Linux Kernel Mailing List
Staging: et131x: prune all the debug code
openbsd-misc
:
Andres Salazar
About priorities in /etc/resolv.conf
Tonnerre LOMBARD
Re: bge0: watchdog timeout
Damien Miller
Re: Patching a SSH 'Weakness'
ropers
Re: Real men don't attack straw men
Tony Abernethy
Re: The Atheros story in much fewer words
Colocation donated by:
Syndicate