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: <48793375.30607@qualcomm.com>
Date:	Sat, 12 Jul 2008 15:43:01 -0700
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Vegard Nossum <vegard.nossum@...il.com>,
	Paul Menage <menage@...gle.com>, Paul Jackson <pj@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, miaox@...fujitsu.com,
	rostedt@...dmis.org, 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

Linus Torvalds wrote:
> 
> On Sat, 12 Jul 2008, Linus Torvalds wrote:
>> This patch almost certainly doesn't work, but let me explain:
> 
> Well, I decided to just take the plunge and test it. It WorksForMe(tm), so 
> it's no _totally_ broken. But I really didn't test it except to see that 
> it still booted, and I don't use cpusets and never saw the original bug, 
> of course.
> 
> But considering how simple it is, if it works for people as a way to work 
> around stupid CPU migration issues due to subtle wakeup calls, I'd almost 
> prefer to really solve this whole issue with that cpu_active_map thing. 
> 
> It's so simple it should be really _robust_ in the presense of problems 
> elsewhere (like the whole cpusets scheduling domain mess).
> 
> Assuming I didn't do anythign stupid, of course, which is why it would 
> definitely need much more testing. And especially if Vegard can test it 
> with the case that oopsed for him due to the bad migration..

My vote goes for Dmitry's patch. The one with the full switch() statement.
Your simplified version with if() is correct (I think) but the switch() is
more explicit about what events are being processed.

The cpu_active_map thing seems like an overkill. In a sense that we should not
try to add a new map for every such case. Granter this migration case may be
special enough to warrant the new map but in general I think it's not the
right way to go.

btw Dmitry's patch should go in anyway. It makes no sense to kill and then
immediately rebuild domains during hotplug sequence.  Actually I might have a
bit better patch. I'm thinking we should just call rebuild_sched_domains() (or
some wrapper) from the sched hotplug handler. That way it'll be clear when
domains are supposed to be created/destroyed. ie We won't have to coordinate
cpu hotplug handling events between scheduler and cpusets. I'll send a patch a
bit later.

Max

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