linux-kernel - Re: disabled APICs being counted as processors ?

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1401260131160.15844@chino.kir.corp.google.com>
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/