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: Tue, 6 Sep 2022 09:26:02 -0700 From: Yury Norov <yury.norov@...il.com> To: Valentin Schneider <vschneid@...hat.com> Cc: Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Rasmus Villemoes <linux@...musvillemoes.dk>, Andrew Morton <akpm@...ux-foundation.org>, Stephen Rothwell <sfr@...b.auug.org.au>, Thomas Gleixner <tglx@...utronix.de>, "Paul E . McKenney" <paulmck@...nel.org>, Vlastimil Babka <vbabka@...e.cz>, Dmitry Vyukov <dvyukov@...gle.com>, Sander Vanheule <sander@...nheule.net>, Alexey Klimov <klimov.linux@...il.com>, Eric Biggers <ebiggers@...gle.com> Subject: Re: [PATCH v2 0/5] cpumask: cleanup nr_cpu_ids vs nr_cpumask_bits mess On Tue, Sep 6, 2022 at 8:45 AM Valentin Schneider <vschneid@...hat.com> wrote: > > On 06/09/22 16:38, Peter Zijlstra wrote: > > On Tue, Sep 06, 2022 at 01:06:47PM +0100, Valentin Schneider wrote: > > > >> #define nr_cpumask_bits nr_cpu_ids > > > > That assumes the CPU space is dense; is this so? That is, you can have 4 > > CPUs while the highest cpu number is vastly larger than 4. It's quite common. One can configure qemu to give to the user one cpu at start, and hotplug more on demand. In that case those unattached CPUS are set in cpu_possible_mask. > > It's uncommon, but not unheard of I think. ISTR some BIOSes leaving > > holes in the CPU space when there were empty CPU sockets on the > > motherboard. Didn't get my hands on that particular board, but I suspect that those missed CPUs will be set in possible mask, and unset in present, online and active masks. > I'd assume this would be visible in the cpu_possible_mask and thus be > properly reflected in nr_cpu_ids. Otherwise that would already break with > CONFIG_CPUMASK_OFFSTACK=y, I think. Yes. The nr_cpu_ids is set as: find_last_bit(cpumask_bits(cpu_possible_mask), NR_CPUS) + 1 For all board and VM configurations I've been working with, the cpu_possible_mask was dense up to nr_cpu_ids.The holes that may appear if HOTPLUG is enabled or by any other reason are all in the present mask, and therefore nr_cpu_ids is set correctly.
Powered by blists - more mailing lists