lkml.org 
[lkml]   [2016]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory
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

\
 
 \ /
  Last update: 2016-11-04 21:58    [W:0.094 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site