Found one x2apic pre-enabled system, x2apic_mode suddenly get corrupted
after register some cpus. when compiled CONFIG_NR_CPUS=255 instead of 512

It turns out that generic_processor_info() ==> phyid_set(apicid, phys_cpu_present_map) cause the problem.

phys_cpu_present_map is with MAX_APICS bits. and pre-enabled system some cpus apic id > 255.

the variable after phys_cpu_present_map may get corrupted.... siliently...

ffffffff828e8420 B phys_cpu_present_map
ffffffff828e8440 B apic_verbosity
ffffffff828e8444 B local_apic_timer_c2_ok
ffffffff828e8448 B disable_apic
ffffffff828e844c B x2apic_mode
ffffffff828e8450 B x2apic_disabled
ffffffff828e8454 B num_processors
...

Actually phys_cpu_present_map is referenced via apic id, instead index. we should use
MAX_LOCAL_APIC instead MAX_APICIS. but that is another header.

So just let MAX_APICS equal to MAX_LOCAL_APIC at this point.
esp for 64 bit will be 32768 in all cases.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/include/asm/mpspec_def.h |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

Index: linux-2.6/arch/x86/include/asm/mpspec_def.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/mpspec_def.h
+++ linux-2.6/arch/x86/include/asm/mpspec_def.h
@@ -17,11 +17,7 @@
 # define MAX_MPC_ENTRY 1024
 # define MAX_APICS      256
 #else
-# if NR_CPUS <= 255
-#  define MAX_APICS     255
-# else
-#  define MAX_APICS   32768
-# endif
+# define MAX_APICS    32768
 #endif
 
 /* Intel MP Floating Pointer Structure */
--

[ message continues ]

Please fix the real bug first: the lack of boundary checks when we set 
phys_cpu_present_map!

Then, once that bitmap op is not corrupting nearby variables silently but triggers a 
fail-safe logic instead (ignoring apics that go outside the supported range? 
printk-ing a warning?) can we think about upping the limit.

But even with the limit upping, please show (in the changelog) a before/after 'size 
vmlinux' comparison, to make sure that this rather drastic change of the limit does 
not waste unreasonable amounts of memory.

Thanks,

	Ingo
--

[ message continues ]