linux-kernel - Re: [patch 00/40] CPU hotplug rework

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:	Fri, 1 Feb 2013 09:55:48 +1100
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	Arjan van de Veen <arjan@...radead.org>,
	Paul Turner <pjt@...gle.com>,
	Richard Weinberger <rw@...utronix.de>,
	Magnus Damm <magnus.damm@...il.com>
Subject: Re: [patch 00/40] CPU hotplug rework - episode I

On Fri, Feb 1, 2013 at 9:44 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> Just face it. The current hotplug maze has 100+ states which are
> completely undocumented. They are asymetric vs. startup and
> teardown. They just exists and work somehow aside of the occasional
> hard to decode hickup.
>
> Do you really want to preserve that state by all means [F*ck no]?

No., But I also don't want to replace it with "there's now eleven
documented states, and random people hook into random documented
states".

So for me it's the "expose these states" that I get worried about.. A
random driver should not necessarily even be able to *see* this, and
decide to be clever and take advantage of the ordering.

So I'd hope there would be some visibility restrictions. We currently
have drivers already being confused by DOWN_PREPARE vs DOWN_FAILED etc
etc random state transitions, and giving them even more flexibility to
pick random states sounds like a really bad idea. I'd like to make
sure that drivers and filesystems etc do not even *see* the states
that are meant for the scheduler or workqueues, for example).

So 11 states (although some of those seem to have lots of substates,
so there may be many more) is too many to *expose*. It's not
necessarily too many to "have and document", if you see the
difference.

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