From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@ucw.cz>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
jan sonnek <ha2nny@gmail.com>,
linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Andy Whitcroft <apw@shadowen.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: Regression - locking (all from 2.6.28)
Date: Mon, 16 Mar 2009 23:04:27 +0100 [thread overview]
Message-ID: <200903162304.28944.rjw@sisk.pl> (raw)
In-Reply-To: <20090306192812.GA26767@elf.ucw.cz>
On Friday 06 March 2009, Pavel Machek wrote:
> Hi!
>
> On Fri 2009-03-06 11:19:46, Dave Hansen wrote:
> > On Fri, 2009-03-06 at 18:00 +0000, Catalin Marinas wrote:
> > > > I think you should be more worried about consistency rather than missing
> > > > entries. Take these two lines of code:
> > > >
> > > > start_pfn = node->node_start_pfn;
> > > > /* hotplug occurs here */
> > > > end_pfn = start_pfn + node->node_spanned_pages;
> > > >
> > > > What if someone comes in and adds memory to the node, at the beginning
> > > > of the node, after you have calculated start_pfn? Try to think of what
> > > > value you'll get for end_pfn and whether it is consistent and was *ever*
> > > > valid at all. Would that oops the kernel?
> > >
> > > I assume pfn_valid() should handle this and kmemleak wouldn't scan the
> > > page, unless we need locks around pfn_valid as well but I haven't seen
> > > any used in the kernel.
> >
> > You assume incorrectly. :(
> >
> > Take my above example, and assume that you have two nodes which are
> > right next to each other. You might run over the end of one node and
> > into the next one. Your pages will be pfn_valid() but you will be on
> > the wrong node.
> >
> > Please take a look at those locks that I mentioned. Notice that they
> > are lock the pgdat *span*, not the validity of pages inside the pgdat.
> > Your code deals with what pages the pgdats *span* and thus needs that
> > lock. Notice that my example also had to do with those two lines of
> > code incorrectly guessing the pgdat's *span*.
> >
> > We recently went to some pain to make sure that the software suspend
> > code (which walks pgdat ranges as well) worked with memory hotplug.
> > There really isn't that much code around that actually cares at runtime
> > about which physical areas a particular node or zone spans. Yours is a
> > rarity and will require some caution.
> >
> > You could probably also use the memory hotplug mutex found here:
> >
> > https://lists.linux-foundation.org/pipermail/linux-pm/2008-November/018884.html
> >
> > But I'm not sure where those patches have gone. Hmmm. Pavel?
>
> I don't think they were applied. They probably should... Rafael was
> about to look into that, but he lost the patch pointer.
Yes. In fact, sending the patch again to me would be appreciated.
Thanks,
Rafael
next prev parent reply other threads:[~2009-03-16 22:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <49AC334A.9030800@gmail.com>
2009-03-02 20:11 ` Regression - locking (all from 2.6.28) Andrew Morton
2009-03-03 10:41 ` Catalin Marinas
2009-03-03 15:01 ` Catalin Marinas
2009-03-05 0:54 ` Dave Hansen
2009-03-05 18:04 ` Catalin Marinas
2009-03-05 18:29 ` Peter Zijlstra
2009-03-06 16:40 ` Catalin Marinas
2009-03-06 16:52 ` Dave Hansen
2009-03-06 17:18 ` Catalin Marinas
2009-03-06 17:26 ` Dave Hansen
2009-03-06 18:00 ` Catalin Marinas
2009-03-06 19:19 ` Dave Hansen
2009-03-06 19:28 ` Pavel Machek
2009-03-16 22:04 ` Rafael J. Wysocki [this message]
2009-03-17 0:07 ` KAMEZAWA Hiroyuki
2009-03-14 16:24 ` Pavel Machek
2009-03-16 17:12 ` Catalin Marinas
2009-03-03 18:12 ` Peter Zijlstra
2009-03-22 4:45 jan sonnek
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=200903162304.28944.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=catalin.marinas@arm.com \
--cc=dave@linux.vnet.ibm.com \
--cc=ha2nny@gmail.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=viro@zeniv.linux.org.uk \
/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