Re: [PATCH] x86, 64bit: Always make MAX_APICS to 32768

[Ingo Molnar]

* Yinghai Lu <yinghai@xxxxxxxxxx> wrote:

> 
> 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@xxxxxxxxxx>
> 
> ---
>  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 */

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/