From: "Yinghai Lu" <yhlu.kernel@gmail.com>
To: "Linus Torvalds" <torvalds@linux-foundation.org>
Cc: "Ingo Molnar" <mingo@elte.hu>,
"Thomas Gleixner" <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Jesse Barnes" <jbarnes@virtuousgeek.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: split e820 reserved entries record to late v4 - fix
Date: Fri, 29 Aug 2008 09:37:06 -0700 [thread overview]
Message-ID: <86802c440808290937y468a4368y9b6ed57ca0cb9896@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.1.10.0808290854000.3300@nehalem.linux-foundation.org>
On Fri, Aug 29, 2008 at 9:05 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> 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
next prev parent reply other threads:[~2008-08-29 16:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-29 8:13 Yinghai Lu
2008-08-29 8:18 ` Yinghai Lu
2008-08-29 16:05 ` Linus Torvalds
2008-08-29 16:37 ` Yinghai Lu [this message]
2008-08-29 16:55 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86802c440808290937y468a4368y9b6ed57ca0cb9896@mail.gmail.com \
--to=yhlu.kernel@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®