linux-kernel - Re: [PATCH 2/2] x86, reschedule: check to see if system is shutting down

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 09:54:29 -0500
From:	Don Zickus <dzickus@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
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, 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?

Cheers,
Don
--
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/