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, 15 Feb 2012 18:59:47 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Don Zickus <dzickus@...hat.com>
Cc:	x86@...nel.org, LKML <linux-kernel@...r.kernel.org>,
	tony.luck@...el.com, seiji.aguchi@....com, ak@...ux.intel.com,
	mjg@...hat.com, levinsasha928@...il.com
Subject: Re: [PATCH 2/2] x86, reschedule: check to see if system is shutting
 down

On Wed, 2012-02-15 at 10:57 -0500, Don Zickus wrote:

> > nope.. same problem, you're not telling anybody you're shooting CPUs
> > down -- this telling is usually done through cpu hotplug notifiers that
> > fix up state.
> 
> Why? If you have successfully sync'd up the cpus, stopped them and then
> run a 'stop_cpu' function, you stop all those WARN_ONs I would think.

So the one you're running in here is native_smp_send_reschedule(), its
send by the scheduler to kick a remote cpu. Doing kstopmachine()
flipping online bits and calling hlt with irqs disabled doesn't inform
the scheduler those CPUs aren't actually around anymore.

>   And
> how much do we care that we fix up the state on a shutdown?  We have
> already shutdown all the processes and unmounted the disks?  Most of the
> drivers have probably been shutdown cleanly.  What is left that we have to
> be polite?

Dunno, probably not much, but things like RCU might just want to try and
wait for remote CPUs to complete their grace period, which'll be a while
with them being quite dead.

There might also still be work left in workqueues, timers left on timer
wheels etc.. timers won't tick since their apic is dead along with the
cpu, so that shouldn't be a big problem unless someone is waiting for
one to complete. Similar with workqueues, I guess since tasks won't get
scheduled.

But the scheduler is still up and thinking its got all these CPUs,
poking them and getting WARNed about it.

> > The only way is to unplug all cpus except the one. Problem with that is
> > that we cannot (as of yet) unplug the boot cpu.
> 
> Yeah, well we can migrate to the boot cpu.  I think powerpc does that for
> kdump.

Right, there's that.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ