linux-kernel - Re: current linux-2.6.git: cpusets completely broken

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: <alpine.LFD.1.10.0807142029280.3017@woody.linux-foundation.org>
Date:	Mon, 14 Jul 2008 20:36:39 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Steven Rostedt <rostedt@...dmis.org>
cc:	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Vegard Nossum <vegard.nossum@...il.com>,
	Paul Menage <menage@...gle.com>,
	Max Krasnyansky <maxk@...lcomm.com>, Paul Jackson <pj@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, miaox@...fujitsu.com,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: current linux-2.6.git: cpusets completely broken

On Mon, 14 Jul 2008, Steven Rostedt wrote:

> 
> On Mon, 14 Jul 2008, Linus Torvalds wrote:
> > So by doing the test for cpu_active_map not at queuing time, but at the
> > time when we actually try to do the migration, we can now also make that
> > cpu_active_map be totally serialized.
> >
> > (Of course, anybody who clears the bit does need to take the runqueue lock
> > of that CPU too, but cpu_down() will have to do that as it does the
> > "migrate away live tasks" anyway, so that's not a problem)
> 
> Wouldn't simply doing a synchronize_sched() after clearing the bit also
> make sure that no new task will be scheduled on that CPU?

My point was that it DOESN'T NEED TO DO ANYTHING AT ALL.

It has to get the runqueue lock in order to move the currently executing 
threads off that CPU anyway. The fact that it can (and actually does) 
synchronize with the scheduler in other ways is totally and utterly 
immaterial.

That's what "robust" means. It means that things just work, and there are 
no subtle interactions.

Sure, you can serialize with something complicated and heavy. 

But isn't it nice that the absolutely _least_ complicated and heavy 
operation (ie getting the runqueue lock) also serializes sufficiently? 
Isn't it nice how you have to do that in order to do all those other 
things that you obviously have to do?

Please don't argue about how we can add more subtle rules, or how other 
thigns can serialize this thing as well. Isn't it sufficient that the 
_obvious_ things serialize it?

		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/