Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1516345
| From | "Charles (Chas) Williams" <ciwillia@brocade.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory |
| Date | 2016-11-07 18:10 +0100 |
| Message-ID | <sAVAK-62m-41@gated-at.bofh.it> (permalink) |
| References | <sz2Q6-6i5-11@gated-at.bofh.it> <szcw2-3Ve-15@gated-at.bofh.it> <sAUY2-5vP-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 11/07/2016 11:19 AM, Thomas Gleixner wrote:
> On Wed, 2 Nov 2016, Charles (Chas) Williams wrote:
>
>> On 11/02/2016 08:25 AM, Sebastian Andrzej Siewior wrote:
>>> I am not sure if this a race with the new hotplug code or something that was
>>> always there. Both (M. Vefa Bicakc and Charles) say that the box boots
>>> sometimes fine (without the patch). smp_store_boot_cpu_info() should have
>>> run
>>> before the notofoert and thus should have set the info properly. However I
>>> got
>>> the following bootlog from Charles with this patch:
>>
>> I don't this this is a race. Here is some debugging from the two CPU VM
>> (2 sockets, 1 core per socket). In identify_cpu() we have:
>>
>> /* The boot/hotplug time assigment got cleared, restore it */
>> c->logical_proc_id = topology_phys_to_logical_pkg(c->phys_proc_id);
>>
>> The values just after this:
>>
>> [ 0.228306] identify_cpu: c ffff88023fd0a040 logical_proc_id 65535
>> c->phys_proc_id 2
>>
>> So what's interesting here, is the phys_proc_id of 2 for CPU1:
>>
>> int topology_phys_to_logical_pkg(unsigned int phys_pkg)
>> {
>> if (phys_pkg >= max_physical_pkg_id)
>> return -1;
>> return physical_to_logical_pkg[phys_pkg];
>> }
>>
>> And we happen to know the max_physical_pkg_id is 2 in this case.
>> So apparently, topology_phys_to_logical_pkg() returns -1 and it gets
>> assigned to the logical_proc_id.
>>
>> I don't know why the CPU's phys_proc_id is 2.
>
> max_physical_pkg_id gets initialized via:
>
> cpus = boot_cpu_data.x86_max_cores;
> max_physical_pkg_id = DIV_ROUND_UP(MAX_LOCAL_APIC, ncpus);
>
> What's the value of boot_cpu_data.x86_max_cores and MAX_LOCAL_APIC?
I have discovered that that is not the problem. smp_init_package_map()
is calculating the physical core id using the following:
for_each_present_cpu(cpu) {
unsigned int apicid = apic->cpu_present_to_apicid(cpu);
...
if (!topology_update_package_map(apicid, cpu))
continue;
...
int topology_update_package_map(unsigned int apicid, unsigned int cpu)
{
unsigned int new, pkg = apicid >> boot_cpu_data.x86_coreid_bits;
But later when the secondary CPU's are identified they use a different
calculation using the local APIC ID from the CPU's registers:
static void generic_identify(struct cpuinfo_x86 *c)
...
if (c->cpuid_level >= 0x00000001) {
c->initial_apicid = (cpuid_ebx(1) >> 24) & 0xFF;
...
c->phys_proc_id = c->initial_apicid;
So at the end of identify_cpu() when the boot/hotplug assignment is
put back:
c->logical_proc_id = topology_phys_to_logical_pkg(c->phys_proc_id);
topology_phys_to_logical_pkg() is returning an invalid logical processor
since one isn't configured.
It's not clear to me what the right thing to do is or which is right.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-11-02 13:30 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory "Charles (Chas) Williams" <ciwillia@brocade.com> - 2016-11-02 23:50 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-11-03 18:50 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory "Charles (Chas) Williams" <ciwillia@brocade.com> - 2016-11-04 13:30 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-11-04 19:10 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory "Charles (Chas) Williams" <ciwillia@brocade.com> - 2016-11-04 21:50 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-11-04 22:00 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Thomas Gleixner <tglx@linutronix.de> - 2016-11-07 17:30 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory "Charles (Chas) Williams" <ciwillia@brocade.com> - 2016-11-07 18:10 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Thomas Gleixner <tglx@linutronix.de> - 2016-11-07 21:30 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory "Charles (Chas) Williams" <ciwillia@brocade.com> - 2016-11-08 15:30 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Thomas Gleixner <tglx@linutronix.de> - 2016-11-08 15:40 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory "Charles (Chas) Williams" <ciwillia@brocade.com> - 2016-11-08 16:00 +0100
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Thomas Gleixner <tglx@linutronix.de> - 2016-11-08 17:30 +0100
[PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner <tglx@linutronix.de> - 2016-11-09 16:40 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner <tglx@linutronix.de> - 2016-11-09 16:50 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Peter Zijlstra <peterz@infradead.org> - 2016-11-09 17:10 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more "Charles (Chas) Williams" <ciwillia@brocade.com> - 2016-11-09 17:40 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner <tglx@linutronix.de> - 2016-11-09 19:50 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more "Charles (Chas) Williams" <ciwillia@brocade.com> - 2016-11-09 19:20 +0100
[tip:x86/urgent] x86/cpu: Deal with broken firmware (VMWare/XEN) tip-bot for Thomas Gleixner <tipbot@zytor.com> - 2016-11-09 21:30 +0100
Re: [tip:x86/urgent] x86/cpu: Deal with broken firmware (VMWare/XEN) Alok Kataria <akataria@vmware.com> - 2016-11-11 07:00 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more "M. Vefa Bicakci" <m.v.b@runbox.com> - 2016-11-10 05:00 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more "Charles (Chas) Williams" <ciwillia@brocade.com> - 2016-11-10 12:00 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner <tglx@linutronix.de> - 2016-11-10 12:20 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner <tglx@linutronix.de> - 2016-11-10 12:20 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Peter Zijlstra <peterz@infradead.org> - 2016-11-10 12:50 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-11-10 15:10 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more "Charles (Chas) Williams" <ciwillia@brocade.com> - 2016-11-10 16:10 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-11-10 16:40 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-11-10 17:00 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner <tglx@linutronix.de> - 2016-11-10 18:20 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner <tglx@linutronix.de> - 2016-11-10 16:20 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-11-10 16:40 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner <tglx@linutronix.de> - 2016-11-10 18:20 +0100
Re: [PATCH] x86/cpuid: Deal with broken firmware once more Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-11-10 19:10 +0100
csiph-web