* Andrew Morton <akpm@linux-foundation.org> wrote:
that came in via the UV-APIC patchset but the warning is entirely
harmless. At that point we've got a single CPU running only so
preemption of that code to another CPU is not possible.
native_smp_prepare_cpus() should probably just disable preemption, that
way we could remove all those ugly preempt disable-enable calls from the
called functions - per the patch below. (not boot tested yet - might
provoke atomic-scheduling warnings if i forgot about some schedule point
in this rather large codepath)
Ingo
------------------->
Subject: x86: disable preemption in native_smp_prepare_cpus
From: Ingo Molnar <mingo@elte.hu>
Date: Fri Apr 18 11:07:10 CEST 2008
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/smpboot.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-x86.q/arch/x86/kernel/smpboot.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/smpboot.c
+++ linux-x86.q/arch/x86/kernel/smpboot.c
@@ -1181,6 +1181,7 @@ static void __init smp_cpu_index_default
*/
void __init native_smp_prepare_cpus(unsigned int max_cpus)
{
+ preempt_disable();
nmi_watchdog_default();
smp_cpu_index_default();
current_cpu_data = boot_cpu_data;
@@ -1237,6 +1238,7 @@ void __init native_smp_prepare_cpus(unsi
printk(KERN_INFO "CPU%d: ", 0);
print_cpu_info(&cpu_data(0));
setup_boot_clock();
+ preempt_enable();
}
/*
* Early setup to make printk work.
--
