linux-kernel - Re: [PATCH -tip/core/rcu 2/6] Introduce cpu_notifier() to handle !HOTPLUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Aug 2009 11:28:57 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Josh Triplett <josht@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, dvhltc@...ibm.com, niv@...ibm.com,
	tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
	hugh.dickins@...cali.co.uk, benh@...nel.crashing.org
Subject: Re: [PATCH -tip/core/rcu 2/6] Introduce cpu_notifier() to handle
	!HOTPLUG_CPU case

On Mon, Aug 17, 2009 at 10:21:59AM -0700, Josh Triplett wrote:
> On Sat, 2009-08-15 at 09:53 -0700, Paul E. McKenney wrote:
> > From: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > 
> > This patch introduces a new cpu_notifier() API that is similar to
> > hotcpu_notifier(), but which also notifies of CPUs coming online during
> > boot in the !HOTPLUG_CPU case.
> [...]
> > --- a/include/linux/cpu.h
> > +++ b/include/linux/cpu.h
> > @@ -48,6 +48,15 @@ struct notifier_block;
> > 
> >  #ifdef CONFIG_SMP
> >  /* Need to know about CPUs going up/down? */
> > +#if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE)
> > +#define cpu_notifier(fn, pri) {					\
> > +	static struct notifier_block fn##_nb __cpuinitdata =	\
> > +		{ .notifier_call = fn, .priority = pri };	\
> > +	register_cpu_notifier(&fn##_nb);			\
> > +}
> > +#else /* #if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE) */
> > +#define cpu_notifier(fn, pri)	do { (void)(fn); } while (0)
> > +#endif /* #else #if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE) */
> 
> These two definitions seem inconsistent.  I think the first one needs to
> change to use do { ... } while(0) as well, so it eats the subsequent
> semicolon.

Ha!  I just copied the old hotcpu_notifier style.  Will send a patch
fixing both.  Or feel free to send one, if you wish.

> Does this really want to live under defined(CONFIG_HOTPLUG_CPU)?  What
> happens when onlining CPUs during the !define(CONFIG_HOTPLUG_CPU) case?
> This seems somewhat inconsistent with the explanation in your commit
> message; can you clarify?

The !MODULE covers the !define(CONFIG_HOTPLUG_CPU) case, please see
below.

> Also, why !defined(MODULE)?

Here is how the cases lay out:

o	!CONFIG_SMP:  there is only one CPU, and so there can be no
	CPU-hotplug operations, even at boot.  Therefore, the
	cpu_notifier() need do nothing.

o	CONFIG_SMP && CPU_HOTPLUG_CPU:  CPUs can come and go at any
	time, so we need cpu_notifier() to actually register a
	notifier.

o	CONFIG_SMP && !CPU_HOTPLUG_CPU && MODULE:  CPUs cannot go
	offline, but they do come online at boot time.	But MODULE means
	that this code is in a module, and modules cannot be loaded
	until later, after all CPUs have come online.  So cpu_notifier()
	need do nothing in this case.

o	CONFIG_SMP && !CPU_HOTPLUG_CPU && !MODULE:  CPUs cannot go
	offline, but they do come online at boot time.  This code
	is not in a module, so might be running at boot time, and
	thus might need to deal with CPUs coming online.  Therefore,
	cpu_notifier() must actually register a notifier.

The difference between hotcpu_notifier() and cpu_notifier() is in this
last case.  You would use hotcpu_notifier() for non-module code that did
not run until all CPUs had come online, and thus would not need to deal
with CPU hotplug unless HOTPLUG_CPU was actually defined.

							Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/