From: Catalin Marinas <catalin.marinas@arm.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: 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>, Pavel Machek <pavel@ucw.cz>
Subject: Re: Regression - locking (all from 2.6.28)
Date: Mon, 16 Mar 2009 17:12:43 +0000 [thread overview]
Message-ID: <1237223563.19000.14.camel@pc1117.cambridge.arm.com> (raw)
In-Reply-To: <1236367186.10626.84.camel@nimitz>
Hi Dave,
> 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.
OK, thanks for taking the time to explain this. I currently added a
dependency on !MEMORY_HOTPLUG for kmemleak since holding the lock while
traversing the page structures is not really feasible.
> You could probably also use the memory hotplug mutex found here:
>
> https://lists.linux-foundation.org/pipermail/linux-pm/2008-November/018884.html
That would be a better option for kmemleak as well.
--
Catalin
next prev parent reply other threads:[~2009-03-16 17:14 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
2009-03-17 0:07 ` KAMEZAWA Hiroyuki
2009-03-14 16:24 ` Pavel Machek
2009-03-16 17:12 ` Catalin Marinas [this message]
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=1237223563.19000.14.camel@pc1117.cambridge.arm.com \
--to=catalin.marinas@arm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=dave@linux.vnet.ibm.com \
--cc=ha2nny@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.