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: <20080713181910.GA22052@elte.hu>
Date:	Sun, 13 Jul 2008 20:19:10 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Dmitry Adamushko <dmitry.adamushko@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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,
	rostedt@...dmis.org, Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: current linux-2.6.git: cpusets completely broken


* Dmitry Adamushko <dmitry.adamushko@...il.com> wrote:

> > So instead of this illogical and crazy mess:
> >
> >        +       switch (phase) {
> >        +       case CPU_UP_CANCELED:
> >        +       case CPU_UP_CANCELED_FROZEN:
> >        +       case CPU_DOWN_FAILED:
> >        +       case CPU_DOWN_FAILED_FROZEN:
> >        +       case CPU_ONLINE:
> >        +       case CPU_ONLINE_FROZEN:
> >        +       case CPU_DEAD:
> >        +       case CPU_DEAD_FROZEN:
> >        +               common_cpu_mem_hotplug_unplug(1);
> >
> > it should just say
> >
> >        +       switch (phase) {
> >        +       case CPU_ONLINE:
> >        +       case CPU_ONLINE_FROZEN:
> >        +       case CPU_DEAD:
> >        +       case CPU_DEAD_FROZEN:
> >        +               common_cpu_mem_hotplug_unplug(1);
> >
> > because it only makes sense to rebuild the scheduler domains when the
> > thing SUCCEEDS.
> >
> > See? By having a sane design, the code is not just more robust and 
> > easy to follow, you can also simplify it and make it more logical.
> 
> Yes, I agree. And I did _not_ say that the current design is sane. My 
> impression about changes acceptable during a late release cycle was 
> utterly CRAPPY (indeed, it's always better to immediately fix a 
> problem the right way, not just add another patch and pray it doesn't 
> break somewhere else).

mind sending Linus's patch as a completed patchset against tip/master 
(or tip/sched/devel) so that we can do it in early v2.6.27?

i still think your cpusets.c fix is what we should do for v2.6.26, given 
that there's agreement about how to fix it for real and thus in terms of 
regression/bug risk your patch is lower-impact and CPU hotplug has been 
broken for such a long time.

But we should follow it up with Linus's patch immediately afterwards in 
v2.6.27. Hm?

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