linux-kernel - Re: [RFC][PATCH 0/4] Redesign cpu

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: <Pine.LNX.4.64.0608261404350.11811@g5.osdl.org>
Date:	Sat, 26 Aug 2006 14:09:55 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Dave Jones <davej@...hat.com>
cc:	Andrew Morton <akpm@...l.org>, ego@...ibm.com,
	rusty@...tcorp.com.au, linux-kernel@...r.kernel.org,
	arjan@...el.linux.com, mingo@...e.hu, vatsa@...ibm.com,
	dipankar@...ibm.com, ashok.raj@...el.com
Subject: Re: [RFC][PATCH 0/4] Redesign cpu_hotplug locking.

On Fri, 25 Aug 2006, Dave Jones wrote:
>
> On Thu, Aug 24, 2006 at 09:17:04AM -0700, Andrew Morton wrote:
>  > We already have sufficient locking primitives to get this right.  Let's fix
>  > cpufreq locking rather than introduce complex new primitives which we hope
>  > will work in the presence of the existing mess.
>  > 
>  > Step 1: remove all mention of lock_cpu_hotplug() from cpufreq.
>  > Step 2: work out what data needs to be locked, and how.
>  > Step 3: implement.
> 
> this is what I planned to do weeks ago when this mess first blew up.
> I even went as far as sending Linus a patch for (1).
> He seemed really gung-ho about trying to fix up the current mess though,
> and with each incarnation since, I've been convinced we're making
> the problem worse rather than really improving anything.

I definitely want to have this fixed, and Gautham's patches look like a 
good thing to me, but the "trying to fix up the current mess" part was 
really about trying to get 2.6.18 in a mostly working state rather than 
anything else. I think it's been too late to try to actually _fix_ it for 
2.6.18 for a long time already.

So my reaction is that this redesign should go in asap after 2.6.18, 
unless people feel strongly that the current locking has so many bugs that 
people can actually _hit_ in practice that it's better to go for the 
redesign early.

I personally doubt that it's the case that we'd want to accelerate 
inclusion - very few things actually do CPU hotplug, and right now the 
only way to even hit the sequences in normal use is literally just the 
"suspend under SMP" case that hasn't historically worked very well anyway, 
but was what made at least me personally aware of the problems ;^).

		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/