Re: [PATCH] x86: Document the hotplug code is incompatible with x86 irq handling

From: ebiederm@xmission.com (Eric W. Biederman)
To: Robert Hancock <hancockr@shaw.ca>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <ak@suse.de>,
	linux-kernel@vger.kernel.org, Neil Brown <neilb@suse.de>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Ingo Molnar <mingo@elte.hu>,
	Zwane Mwaikambo <zwane@linuxpower.ca>
Subject: Re: [PATCH] x86: Document the hotplug code is incompatible with x86 irq handling
Date: Thu, 31 May 2007 09:47:22 -0600	[thread overview]
Message-ID: <m1abvl3shh.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <465EDCF4.7010700@shaw.ca> (Robert Hancock's message of "Thu, 31 May 2007 08:34:28 -0600")

Robert Hancock <hancockr@shaw.ca> writes:

> Eric W. Biederman wrote:
>> I just realized that except for doing the code review and noticing
>> that the current cpu hotplug code is fundamentally incompatible
>> with x86 I haven't done anything about it.  So here is my patch
>> to document what is wrong.
>>
>> The current cpu hotplug code requires irqs to be migrated from a cpu
>> outside of irq context.  On x86 ioapics simply do not support this,
>> making the code unfixable without major redesign of the generic cpu
>> hotplug code.
>>
>> So this patch makes CPU_HOTPLUG on x86 depend on CONFIG_BROKEN
>> and adds a WARN_ON so people that do enable it are not in doubt about
>> which part of the code is broken, even if it does work for them.
>>
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>
> I don't think this is useful, though the code may be problematic, this patch
> will break suspend on all SMP machines with an existing config, which is a major
> regression..

Cool.

My patch does not change the functionality of the code just complains
very loudly that it is broken.

Further the code is broken at a design level.  The code isn't
problematic the code is impossible.  The cpu hotplug code can not be
fixed on x86 without a redesign of the generic cpu hotplug code.

Suspend does not need to use cpu hotplug because it already gets in
deep with the drivers, and can stop interrupts at the source.  I know
there was some talk about this doing this earlier, but I don't know if
anything came of that discussion.

Regardless if you care about this being a problem feel free to fix the
relevant code so it attempts to do something that the hardware
actually supports.

But if the suspend needs this code for smp support it is also broken.

Eric