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: Sun, 26 Jan 2014 01:44:20 -0800 (PST) From: David Rientjes <rientjes@...gle.com> To: Ingo Molnar <mingo@...nel.org> cc: Dave Jones <davej@...hat.com>, x86@...nel.org, Linux Kernel <linux-kernel@...r.kernel.org>, Yinghai Lu <yinghai@...nel.org> Subject: Re: disabled APICs being counted as processors ? On Sun, 26 Jan 2014, Ingo Molnar wrote: > > > So the problem is that the counting of disabled but hotpluggable > > > CPUs is over-eager. > > > > In the kernel, yeah, and we don't distinguish between physically > > absent processors that have lapic entries and physically present but > > disabled processors. > > Correct. Is there a robust distinction possible between the two? > Not with acpi, I'm afraid, which allows for both possibilities to either have no lapic entry or have ACPI_MADT_ENABLED clear. > > > --- a/arch/x86/kernel/smpboot.c > > > +++ b/arch/x86/kernel/smpboot.c > > > @@ -1223,10 +1223,7 @@ __init void prefill_possible_map(void) > > > i = setup_max_cpus ?: 1; > > > if (setup_possible_cpus == -1) { > > > possible = num_processors; > > > -#ifdef CONFIG_HOTPLUG_CPU > > > - if (setup_max_cpus) > > > - possible += disabled_cpus; > > > -#else > > > +#ifndef CONFIG_HOTPLUG_CPU > > > if (possible > i) > > > possible = i; > > > #endif > > > > Yeah, this should suppress the warning for Dave. This way, the only way > > the log reports the number of "hotplug CPUs" is because we used > > possible_cpus. > > Not just that, it also reduces the number of possible CPUs, which > should reduce percpu memory allocation overhead, amongst other things, > right? > Indeed, it gives people a good motivation for clearing out those unnecessary lapic entries :) > I wouldn't object to someone sending a changelogged, tested patch that > does all that. Maybe two patches: first the cleanups, then the CPU > count trimming. Just in case it regresses ... > Sounds good. I need to look into your point about kexec as far as the possible count trimming first for the second patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists