Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1515347
| From | Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory |
| Date | 2016-11-04 19:10 +0100 |
| Message-ID | <szR69-5cS-3@gated-at.bofh.it> (permalink) |
| References | <sz2Q6-6i5-11@gated-at.bofh.it> <szcw2-3Ve-15@gated-at.bofh.it> <szujg-70x-35@gated-at.bofh.it> <szLN7-1Em-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 2016-11-04 08:20:37 [-0400], Charles (Chas) Williams wrote: > The initial CPU boots and is identified: > > [ 0.009018] identify_boot_cpu > [ 0.009174] generic_identify: phys_proc_id is now 0 > ... > [ 0.009427] identify_cpu: before c ffffffff81ae2680 logical_proc_id 0 c->phys_proc_id 0 > [ 0.009506] identify_cpu: after c ffffffff81ae2680 logical_proc_id 65535 c->phys_proc_id 0 > > So, this is fine because the APIC hasn't been scanned yet. APIC > now gets scanned: > > [ 0.015789] smpboot: APIC(0) Converting physical 0 to logical package 0, cpu 0 (ffff88023fc0a040) > [ 0.015794] smpboot: APIC(1) Converting physical 1 to logical package 1, cpu 1 (ffff88023fd0a040) > [ 0.015797] smpboot: Max logical packages: 2 where is the APICID here is comming from? > So, at this point, I think everything is correct. But now the secondary > CPU's "boot": > > [ 0.236569] identify_secondary_cpu > [ 0.236620] generic_identify: phys_proc_id is now 2 so here is where fun starts. Xen has also arch/x86/xen/smp.c::cpu_bringup() where the phys_proc_id is changed. But isn't done for vmware but it might a place where they duct tape things. How is this APIC id different from the earlier? I guess based on your output that generic_identify() changes the content of phys_proc_id. > [ 0.236745] identify_cpu: before c ffff88023fd0a040 logical_proc_id 65535 c->phys_proc_id 2 > [ 0.236747] identify_cpu: after c ffff88023fd0a040 logical_proc_id 65535 c->phys_proc_id 2 > > So, APIC discovered I have a cpu 0 and 1 but generic_identify() is called > my second CPU, 2. This is >= max_physical_pkg_id, so it is going to get > set to -1. Now. max_physical_pkg_id is huge. The physical_to_logical_pkg array is set to -1 on init so slot two has the value -1. That is what you see - not the -1 because of ">= max_physical_pkg_id". > The comment at the end of identfy_cpu() says: > > /* The boot/hotplug time assigment got cleared, restore it */ > > So, logical_proc_id being wrong here before restoration doesn't bother > me since I assume something in booting the secondary CPU's clears any > existing cpu data. > > I know detect_extended_topology() is likely being called for both CPU's > and getting the right values (checking this now). I don't know why > generic_identify() is resetting this value. I don't know either. But it is clearly reading the apic id twice and second approach is different from the first which leads to different results. So if you figure out how the first APICID for the second CPU is retrieved and then you see how it happens for the second time. There must be a difference. Sebastian
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