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]
Date:	Mon, 10 Jan 2011 20:04:21 +0600
From:	Rakib Mullick <rakib.mullick@...il.com>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>, x86@...nel.org
Subject: Re: [PATCH] x86, apic: Do not increment disabled_cpus from generic_processor_info.

On Mon, Jan 10, 2011 at 3:57 PM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> On 01/10/2011 07:06 AM, Rakib Mullick wrote:
>> On Mon, Jan 10, 2011 at 12:38 AM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
>>>
>> When we use nr_cpus=n, it works as an upper limit. If there are any
>> other CPUs beyond that limit those are not counted and we couldn't put
>> them back on work. So, when we couldn't use hotpluging feature to back
>> them into work, should we care about them?
>>
>
>  Yes we should, the cpus which are present but offlined (due to maxcpus
> or whatever reason) are listed in sysfs so i fear such a change would
> break compatibility with userspace as well.
>
For an example, there are 4 CPUs, we did nr_cpus=2 at boot time. Then
using hotpluging feature we can put CPUs online or offline only these
two CPUs, not the 3rd or 4th CPUs that we left out at startup. But, by
incrementing disabled_cpus at generic_processor_info we are accouting
those two left out CPUs. And latter on at cpumask build up (in
smpboot.c) we're using disabled_cpus to build cpumask bit.

So, as you are fearing about sysfs listing, those maybe right but only
for CPUs we have by passing nr_cpus.

>  Rakib, don't get me wrong, I don't like to complain but the side effect
> of the patch might be pretty inconvenient.
>
It's okay. My primary intention was to raise the issue and have some
disscussion about it. Not necessarily, it must have to included. And
it also helps to clear up the concept and that is why was expecting
Ingo's opinion.


thanks,
rakib

> --
>    Cyrill
>
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ