From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: nickpiggin@yahoo.com.au, vegard.nossum@gmail.com, mingo@elte.hu,
stable@kernel.org, npiggin@suse.de, penberg@cs.helsinki.fi,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: fix lazy vmap purging (use-after-free error)
Date: Mon, 23 Feb 2009 12:12:36 -0800 [thread overview]
Message-ID: <20090223201236.GS6751@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090223115926.ed03e954.akpm@linux-foundation.org>
On Mon, Feb 23, 2009 at 11:59:26AM -0800, Andrew Morton wrote:
> On Mon, 23 Feb 2009 11:30:57 -0800
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> > On Mon, Feb 23, 2009 at 11:10:09AM -0800, Andrew Morton wrote:
> > > On Mon, 23 Feb 2009 08:17:26 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > > On Tue, Feb 24, 2009 at 12:29:36AM +1100, Nick Piggin wrote:
> > > > > On Monday 23 February 2009 16:17:09 Paul E. McKenney wrote:
> > > > >
> > > > > > The boot CPU runs in the context of its idle thread during boot-up.
> > > > > > During this time, idle_cpu(0) will always return nonzero, which will
> > > > > > fool Classic and Hierarchical RCU into deciding that a large chunk of
> > > > > > the boot-up sequence is a big long quiescent state. This in turn causes
> > > > > > RCU to prematurely end grace periods during this time.
> > > > > >
> > > > > > This patch creates a new global variable that is set to 1 just before
> > > > > > the boot CPU first enters the scheduler, after which the idle task
> > > > > > really is idle.
> > > > >
> > > > > Nice work all (btw. if this patch goes in rather than using system_state,
> > > > > then please make the variable __read_mostly).
> > > >
> > > > Hmmm... I misread this and made system_state be __read_mostly. Let
> > > > me know if this is bad, easy to fix if needed.
> > >
> > > Please don't use system_state. The whole thing is just bad design.
> > > It's a global variable, breaks encapsulation, creates interactions etc.
> > > CS-101 stuff.
> >
> > OK. Would it help if I wrapped an accessor function around system_state?
>
> That doesn't help the core problem: system_state creates interactions
> between unrelated subsystems. And the number of interactions grows
> exponentially with the number of subsystems which use system_state.
>
> > I do need some sort of global state if I am to solve this problem. ;-)
>
> As I suggested before, please add a new state variable which is private
> to your subsystem. That way it remains isolated from other subsystems.
OK, so my thought would be to have a function call into RCU from either
init_post() or from rest_init(). This function would then set a variable
private to RCU.
Seem reasonable?
Thanx, Paul
next prev parent reply other threads:[~2009-02-23 20:12 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-20 13:41 [PATCH] mm: fix lazy vmap purging (use-after-free error) Vegard Nossum
2009-02-20 13:50 ` Ingo Molnar
2009-02-20 13:58 ` Pekka Enberg
2009-02-20 14:01 ` Ingo Molnar
2009-02-20 14:18 ` Pekka Enberg
2009-02-20 15:41 ` Paul E. McKenney
2009-02-20 14:51 ` Vegard Nossum
2009-02-20 15:46 ` Paul E. McKenney
2009-02-20 16:04 ` Ingo Molnar
2009-02-20 16:44 ` Paul E. McKenney
2009-02-20 17:14 ` Ingo Molnar
2009-02-20 17:25 ` Paul E. McKenney
2009-02-20 23:51 ` Vegard Nossum
2009-02-21 1:40 ` Paul E. McKenney
2009-02-21 9:30 ` Vegard Nossum
2009-02-21 17:47 ` Paul E. McKenney
2009-02-21 18:08 ` Vegard Nossum
2009-02-21 18:33 ` Paul E. McKenney
2009-02-21 18:37 ` Vegard Nossum
2009-02-22 3:00 ` Paul E. McKenney
2009-02-23 5:17 ` Paul E. McKenney
2009-02-23 8:24 ` Vegard Nossum
2009-02-23 15:39 ` Paul E. McKenney
2009-02-23 9:07 ` Ingo Molnar
2009-02-23 9:17 ` Andrew Morton
2009-02-23 9:27 ` Ingo Molnar
2009-02-23 15:56 ` Paul E. McKenney
2009-02-23 13:29 ` Nick Piggin
2009-02-23 16:17 ` Paul E. McKenney
2009-02-23 17:20 ` Ingo Molnar
2009-02-23 19:10 ` Andrew Morton
2009-02-23 19:30 ` Paul E. McKenney
2009-02-23 19:59 ` Andrew Morton
2009-02-23 20:12 ` Paul E. McKenney [this message]
2009-02-23 20:30 ` Andrew Morton
2009-02-23 19:33 ` Ingo Molnar
2009-02-23 20:04 ` Andrew Morton
2009-02-23 20:09 ` Ingo Molnar
2009-02-23 20:44 ` Paul E. McKenney
2009-02-23 20:43 ` Paul E. McKenney
2009-02-24 3:23 ` Nick Piggin
2009-02-24 3:37 ` Paul E. McKenney
2009-02-21 19:21 ` Vegard Nossum
2009-02-20 16:01 ` Ingo Molnar
2009-02-20 16:49 ` Paul E. McKenney
2009-02-20 15:56 ` Paul E. McKenney
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=20090223201236.GS6751@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=npiggin@suse.de \
--cc=penberg@cs.helsinki.fi \
--cc=stable@kernel.org \
--cc=vegard.nossum@gmail.com \
/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.