Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757377AbcKDU54 (ORCPT ); Fri, 4 Nov 2016 16:57:56 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:42323 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754306AbcKDU5z (ORCPT ); Fri, 4 Nov 2016 16:57:55 -0400 Date: Fri, 4 Nov 2016 21:57:46 +0100 From: Sebastian Andrzej Siewior To: "Charles (Chas) Williams" Cc: x86@kernel.org, linux-kernel@vger.kernel.org, "M. Vefa Bicakci" Subject: Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Message-ID: <20161104205746.yazddirphm736zpa@linutronix.de> References: <20161102122557.qs4rl6mb7n7l7j7p@linutronix.de> <24e69019-60d0-29e7-e31f-c6f00f9ed98a@brocade.com> <20161103174753.o5ynquul2rjuiq77@linutronix.de> <20161104180313.wyaheuajevkrf6o7@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1470 Lines: 40 On 2016-11-04 16:42:33 [-0400], Charles (Chas) Williams wrote: > This comes from here: > > unsigned int apicid = apic->cpu_present_to_apicid(cpu); > > if (apicid == BAD_APICID || !apic->apic_id_valid(apicid)) > continue; > if (!topology_update_package_map(apicid, cpu)) It is late here. Can you check what function apic->cpu_present_to_apicid is? It should do the right thing for your APIC. > The phys core id from generic_identify() comes from the CPU's EBX register > so we _know_ this is right. So you are sure cpuid_level is > 1 here. > if (c->cpuid_level >= 0x00000001) { > c->initial_apicid = (cpuid_ebx(1) >> 24) & 0xFF; > #ifdef CONFIG_X86_32 > # ifdef CONFIG_SMP > c->apicid = apic->phys_pkg_id(c->initial_apicid, 0); > # else > c->apicid = c->initial_apicid; > # endif > #endif > c->phys_proc_id = c->initial_apicid; > } > > The intel docs http://x86.renejeschke.de/html/file_module_x86_id_45.html > claims this is the Local APIC ID. So it seems likely this is correct > value. It's not clear it matter if this is the right value or not > though. Even if this is the correct apicid, nothing knows about it. Need to check that later (and your whole mail) against an official manual. But as you see in the code, it checks the apicid against ->phys_pkg_id on 32bit so it seems sometimes there are changes required to what the CPUID returns. Sebastian