Re: [PATCH 2/2] x86, reschedule: check to see if system is shuttingdown

[Don Zickus]

On Wed, Feb 15, 2012 at 03:57:15PM +0100, Peter Zijlstra wrote:
> On Wed, 2012-02-15 at 09:54 -0500, Don Zickus wrote:
> > On Wed, Feb 15, 2012 at 12:26:37PM +0100, Peter Zijlstra wrote:
> > > 
> > > Right, so this fixes this one particular case, I imagine there's tons of
> > > places that could go splat due to this (but don't quite yet for some
> > > reason).
> > > 
> > > We can't go around annotating everything, nor would we want to simply
> > > shut up all warnings for fear of missing an actual error.
> > > 
> > > Why can't the normal shut-down path use a less crazy approach to going
> > > down?
> > 
> > Well maybe it can, it's been like that way for over three years now.  I'm
> > surprised no one ran into issues before now.
> > 
> > The only thing I can think that would work is stop_machine().  Pass in a
> > halt function and a cpumask of everyone but smp_processor_id().  That
> > would solve the problem, no?
> 
> 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.  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?

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

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