From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Catalin Marinas <catalin.marinas@arm.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>
Subject: Re: Regression - locking (all from 2.6.28)
Date: Fri, 06 Mar 2009 09:26:55 -0800 [thread overview]
Message-ID: <1236360415.10626.67.camel@nimitz> (raw)
In-Reply-To: <1236359888.3882.77.camel@pc1117.cambridge.arm.com>
On Fri, 2009-03-06 at 17:18 +0000, Catalin Marinas wrote:
> > > Are the pgdat->node_start_pfn and pgdat->node_spanned_pages always
> > > valid? Thanks.
> >
> > The variables themselves? I'm sure there's a window in early boot where
> > they aren't valid, but other than that they should be OK unless you're
> > int the middle of a hotplug operation.
> >
> > See pgdat_resize_(un)lock() in include/linux/memory_hotplug.h.
>
> I wouldn't hold a lock for that long. It's not really critical to scan
> all the page structures at a time as there are subsequent scans as well,
> so some can be missed.
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?
-- Dave
next prev parent reply other threads:[~2009-03-06 17:27 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 [this message]
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
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=1236360415.10626.67.camel@nimitz \
--to=dave@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=catalin.marinas@arm.com \
--cc=ha2nny@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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.