From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758059AbcHCQY0 (ORCPT ); Wed, 3 Aug 2016 12:24:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45948 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757621AbcHCQYY (ORCPT ); Wed, 3 Aug 2016 12:24:24 -0400 Date: Wed, 3 Aug 2016 18:23:58 +0200 From: Jiri Olsa To: Thomas Gleixner Cc: Andi Kleen , Peter Zijlstra , linux-kernel@vger.kernel.org, Andi Kleen , x86@kernel.org, Ingo Molnar , Frank Ramsay Subject: [RFC][PATCH] x86/smp: Fix __max_logical_packages value setup Message-ID: <20160803162358.GA10890@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.2 (2016-07-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 03 Aug 2016 16:24:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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:[] [] uncore_change_context+0xd4/0x180^M ... [] uncore_event_init_cpu+0x6c/0x70^M [] intel_uncore_init+0x1c2/0x2dd^M [] ? uncore_cpu_setup+0x17/0x17^M [] do_one_initcall+0x50/0x190^M [] ? parse_args+0x293/0x480^M [] kernel_init_freeable+0x1a5/0x249^M [] ? set_debug_rodata+0x12/0x12^M [] kernel_init+0xe/0x110^M [] ret_from_fork+0x1f/0x40^M [] ? 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 Signed-off-by: Jiri Olsa --- 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