linux-kernel - Re: [PATCH 0/4] arch/CPU hotplug: Add missing CPU Hotplug bits to fix nasty issues

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: <1332427989.2946.20.camel@dabdike.int.hansenpartnership.com>
Date:	Thu, 22 Mar 2012 14:53:09 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	rkuo@...eaurora.org, tglx@...utronix.de, linas@...eaurora.org,
	mingo@...e.hu, dhowells@...hat.com,
	yasutake.koichi@...panasonic.com, akpm@...ux-foundation.org,
	benh@...nel.crashing.org, jesper.nilsson@...s.com,
	cmetcalf@...era.com, linux@....linux.org.uk, jejb@...isc-linux.org,
	deller@....de, vapier@...too.org, linux-hexagon@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-am33-list@...hat.com,
	linux-parisc@...r.kernel.org
Subject: Re: [PATCH 0/4] arch/CPU hotplug: Add missing CPU Hotplug bits to
 fix nasty issues

On Thu, 2012-03-22 at 13:13 +0100, Peter Zijlstra wrote:
> On Thu, 2012-03-22 at 16:58 +0530, Srivatsa S. Bhat wrote:
> > Commit 5fbd036b552f633abb394a319f7c62a5c86a9cd7 (sched: Cleanup cpu_active
> > madness) introduced some changes that made the scheduler rely on the
> > CPU_STARTING notifier. And hence those architectures which forgot to
> > send out the CPU_STARTING notification will almost surely get into trouble.
> > (Xen is one example[1]). 
> 
> The requirement is that CPU_STARTING is ran before set_cpu_online() or
> the open-coded equivalent -- eg. blackfin gets this wrong.
> 
> However, it is also required that all this happens while local IRQs are
> still disabled, since the moment we enable IRQs interrupts can happen
> and interrupts can cause wakeups, and wakeups need to have this state
> set up -- blackfin, cris, m32r, mips, sh, sparc64, sparc32, um?, x86 get
> this wrong.
> 
> Furthermore, all archs that use CONFIG_USE_GENERIC_SMP_HELPERS should
> hold ipi_call_lock() over setting the cpu online -- alpha, arm, m32r,
> mips, sh, sparc32 seem wrong.

So for parisc, anywhere in smp_callin() should be fine.  Our last act on
CPU bringup before going into cpu_idle() is to enable interrupts.

> Furthermore, I was pondering the scenario where a 3rd cpu IPIs the newly
> booting cpu, I suspect we need a smp_wmb() after setting cpu_active and
> a rmb in select_fallback_rq() before reading active.
> 
> All in all its a complete friggin trainwreck.

I haven't yet actually tried git head on parisc (and I won't be able to
until I actually get my machines back [currently being shipped across
the atlantic]) but if there's a problem it will show up quickly:  parisc
actually uses cpu hotplug to boot its secondary cpus.

James


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