linux-kernel - Re: [RFC][PATCH] x86/smp: Fix __max_logical

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: <20160810114114.GB4948@krava>
Date:	Wed, 10 Aug 2016 13:41:14 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
	x86@...nel.org, Ingo Molnar <mingo@...nel.org>,
	Frank Ramsay <framsay@...hat.com>
Subject: Re: [RFC][PATCH] x86/smp: Fix __max_logical_packages value setup

ping

thanks,
jirka

On Wed, Aug 03, 2016 at 06:23:58PM +0200, Jiri Olsa wrote:
> Frank reported kernel panic when he disabled several cores in BIOS
> via following option:
> 
>   Core Disable Bitmap(Hex)   [0]
> 
> with number 0xFFE, which leaves 16 CPUs in system (out of 48).
> 
> The kernel panic below goes along with following messages:
> 
>  smpboot: Max logical packages: 2^M
>  smpboot: APIC(0) Converting physical 0 to logical package 0^M
>  smpboot: APIC(20) Converting physical 1 to logical package 1^M
>  smpboot: APIC(40) Package 2 exceeds logical package map^M
>  smpboot: CPU 8 APICId 40 disabled^M
>  smpboot: APIC(60) Package 3 exceeds logical package map^M
>  smpboot: CPU 12 APICId 60 disabled^M
>  ...
>  general protection fault: 0000 [#1] SMP^M
>  Modules linked in:^M
>  CPU: 15 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc5+ #1^M
>  Hardware name: SGI UV300/UV300, BIOS SGI UV 300 series BIOS 05/25/2016^M
>  task: ffff8801673e0000 ti: ffff8801673ac000 task.ti: ffff8801673ac000^M
>  RIP: 0010:[<ffffffff81014d54>]  [<ffffffff81014d54>] uncore_change_context+0xd4/0x180^M
>  ...
>   [<ffffffff810158ac>] uncore_event_init_cpu+0x6c/0x70^M
>   [<ffffffff81d8c91c>] intel_uncore_init+0x1c2/0x2dd^M
>   [<ffffffff81d8c75a>] ? uncore_cpu_setup+0x17/0x17^M
>   [<ffffffff81002190>] do_one_initcall+0x50/0x190^M
>   [<ffffffff810ab193>] ? parse_args+0x293/0x480^M
>   [<ffffffff81d87365>] kernel_init_freeable+0x1a5/0x249^M
>   [<ffffffff81d86a35>] ? set_debug_rodata+0x12/0x12^M
>   [<ffffffff816dc19e>] kernel_init+0xe/0x110^M
>   [<ffffffff816e93bf>] ret_from_fork+0x1f/0x40^M
>   [<ffffffff816dc190>] ? rest_init+0x80/0x80^M
> 
> The reason for the panic is wrong value of __max_logical_packages,
> which lets logical_package_map uninitialized and the uncore code
> relying on this map being properly initialized (maybe we should
> add some safety checks there as well).
> 
> The __max_logical_packages is computed as:
> 
>   DIV_ROUND_UP(total_cpus, ncpus);
>   - ncpus being number of cores
> 
> With above BIOS setup we get total_cpus == 16 which set
> __max_logical_packages to 2 (ncpus is 12). 
> 
> Once topology_update_package_map processes CPU with logical
> pkg over 2 we display above messages and fail to initialize
> the physical_to_logical_pkg map, which makes the uncore code
> crash.
> 
> The fix is to set __max_logical_packages directly to total_cpus,
> which should be the maximum possible logical ID of the pkg in
> any case.
> 
> Reported-by: Frank Ramsay <framsay@...hat.com>
> Signed-off-by: Jiri Olsa <jolsa@...nel.org>
> ---
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 157bf0957219..484f7d357c77 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -340,7 +340,7 @@ static void __init smp_init_package_map(void)
>  		ncpus = 1;
>  	}
>  
> -	__max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
> +	__max_logical_packages = total_cpus;
>  
>  	/*
>  	 * Possibly larger than what we need as the number of apic ids per