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]

Message-ID: <alpine.LFD.2.02.1207261248130.32033@ionos>
Date:	Thu, 26 Jul 2012 12:55:57 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
cc:	Alan Stern <stern@...land.harvard.edu>, mingo@...nel.org,
	peterz@...radead.org, rusty@...tcorp.com.au,
	paulmck@...ux.vnet.ibm.com, 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, Srivatsa S. Bhat wrote:
> On 07/25/2012 10:00 PM, Thomas Gleixner wrote:
> > struct hotplug_event hotplug_events_bp[CPU_HOTPLUG_MAX_EVENTS];
> > struct hotplug_event hotplug_events_ap[CPU_HOTPLUG_MAX_EVENTS];
> >    
> > The _bp one is the list of events which are executed on the active cpu
> > and the _ap ones are those executed on the hotplugged cpu.
> > 
> > The core code advances the events in sync steps, so both BP and AP can
> > issue a stop on the process and cause a rollback.
> 
> What exactly does "sync steps" mean in this context? Also, for the CPU

Sync step means, that both sides need to synchronize - not at every
step, but at well defined synchronization points. You can't advance
the AP to online state unless the BP has done the preparatory stuff
already.

> offline event, the event could start off with both the BP and the AP being
> the same CPU.. Does this design take care of that case?

Once the AP leaves the state where tasks can be freely scheduled on
it, the take down thread migrates automagically. And that's one of the
first things I'm trying to do so the first synchronization point is
after that.

Thanks,

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