linux-kernel - Re: [RFC PATCH 0/6] CPU hotplug: Reverse invocation of notifiers during CPU 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:	Wed, 25 Jul 2012 15:44:21 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	<tglx@...utronix.de>, <mingo@...nel.org>, <peterz@...radead.org>,
	<rusty@...tcorp.com.au>, <namhyung@...nel.org>, <tj@...nel.org>,
	<rjw@...k.pl>, <nikunj@...ux.vnet.ibm.com>,
	<linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/6] CPU hotplug: Reverse invocation of notifiers
 during CPU hotplug

On Wed, 25 Jul 2012, Paul E. McKenney wrote:

> > I think the best you can do is stop using notifiers and use something 
> > else instead.  For example, a simple set of function calls (assuming 
> > you know beforehand what callbacks need to be invoked).
> 
> Unfortunately, we don't know beforehand.  There are loadable kernel
> modules that need to be informed of CPU hotplug events.  So we do need
> some runtime way to register to be notified CPU-hotplug events.
> 
> If it weren't for the modules, we might be able to use another data
> section and get a contiguous list of functions that need to be called.
> I suppose we could have such sections for modules and link/unlink them
> at module load/unload time, but it is not at all clear to me that this
> would be simpler than using notifiers.
> 
> But always happy to learn -- any specific suggestions?

Not knowing the details of CPU hotplug, it's hard to answer in anything 
but generalities.  :-)  (And FYI, I have no intention of learning the 
details of CPU hotplug -- there's enough on my plate already.)

Still, one possibility would be to organize matters by adding a couple
of steps to Thomas's list that would be devoted purely to callbacks and
associating a separate notifier chain to each of these steps.  That way
most of the important work would be kept in the core kernel but modules
could still step in where needed.  The different notifier chains would 
then be strictly ordered with respect to each other, but events within 
a particular chain would not have any specified ordering properties.

Also, Thomas may have mentioned something about having separate 
callbacks for the CPU-up and CPU-down events, instead of relying on one 
list that would be called forwards and backwards.

> > > One of the other ideas to improve the hotplug notifier stuff that came up during some
> > > of the discussions was to implement explicit dependency tracking between the notifiers
> > > and perhaps get rid of the priority numbers that are currently being used to provide
> > > some sort of ordering between the callbacks. Links to some of the related discussions
> > > are provided below.
> > 
> > This seems like misplaced over-engineering.
> 
> In fact, we have deferred dependency tracking.  If I remember correctly,
> the main motivation was to execute notifiers in parallel, but the fraction
> of time that hotplug spends executing notifiers proved to be quite small.
> At this point, I would be surprised if we ever do much with dependency
> tracking.
> 
> Again, any specific suggestions for improvement?

If it works okay without dependency tracking, leave well enough alone.  
:-)

Alan Stern

--
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/