lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 18 Feb 2016 11:25:22 +0100 (CET) From: Thomas Gleixner <tglx@...utronix.de> To: Stephane Eranian <eranian@...gle.com> cc: Peter Zijlstra <peterz@...radead.org>, Andi Kleen <andi@...stfloor.org>, LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>, Harish Chegondi <harish.chegondi@...el.com>, Kan Liang <kan.liang@...el.com>, Andi Kleen <andi.kleen@...el.com> Subject: Re: [patch 07/11] x86/perf/uncore: Track packages not per cpu data Stephane, On Thu, 18 Feb 2016, Stephane Eranian wrote: > On Thu, Feb 18, 2016 at 12:13 AM, Peter Zijlstra <peterz@...radead.org> wrote: > > Now clearly, BIOS can completely wreck things and indeed report too > > small an apic_id range or whatever, and in this case we're up a creek > > without a paddle. > > > > But I think you can check for that at boot and report errors/warns > > whatever, because if you trigger this, your system is not really > > 'correct' anyway. > > > The example I was worried about is as follows, take an Ivytown system > (IVT) with 12 physical cores per package on a 2 socket system. > > Thomas's topology_max_packages() macro would return 2, for 2 packages > with CPU0..CPU47. > > But let's assume that the BIOS does some weird mappings and that the > id for socket0 is indeed 0 > but for socket1 it is 255. Then doing: > > pkg = topology_physical_package_id(); > pmu->boxes[pkg]; > > Would crash because the boxes[] has space for 2 elements and not 256. Right. It did not occur to me that this might be possible, but as I said in my reply to Peter, we can simply create logical package ids and use them. That makes us safe against BIOS tinkering. > If we know this cannot happen, then the code is fine. If we are not > sure, then I believe a check should be added > and if a mismatch is found, then the uncore PMU init code should > return an error. That's all I was trying to point > out. I think Thomas' code is indeed a good simplification. I'm glad you like it. Thanks, tglx
Powered by blists - more mailing lists