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 09:13:20 +0100 From: Peter Zijlstra <peterz@...radead.org> To: Andi Kleen <andi@...stfloor.org> Cc: Thomas Gleixner <tglx@...utronix.de>, Stephane Eranian <eranian@...gle.com>, 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 On Wed, Feb 17, 2016 at 11:16:40PM +0100, Andi Kleen wrote: > > Do you have any data to back that up or is that just "believe" ? > > I've seen systems with discontiguous apic ids before. > > It is obvious if you consider setups with node hotplug. Those systems will also have a num_possible_cpus() that's inflated to account for the possible hotplug of new sockets, right? So while the phys_pkg_id of the present sockets might be 2 and 3 (leaving 0 and 1 available for hotplug), the num_possible_cpus() should be big enough to actually allow for that hotplug to happen. Because if num_possible_cpus() is too small, we could not accommodate the hotplug operation. And if num_possible_cpus() is of the right size, then the computed max_packages() should be of the right size too. 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.
Powered by blists - more mailing lists