linux-kernel - Re: [patch 06/19] sched/mmcid: Prevent pointless work in mm_update_cpus

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: <20251017181911.GR1386988@noisy.programming.kicks-ass.net>
Date: Fri, 17 Oct 2025 20:19:11 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
	Gabriele Monaco <gmonaco@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Michael Jeanson <mjeanson@...icios.com>,
	Jens Axboe <axboe@...nel.dk>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	"Gautham R. Shenoy" <gautham.shenoy@....com>,
	Florian Weimer <fweimer@...hat.com>,
	Tim Chen <tim.c.chen@...el.com>,
	TCMalloc Team <tcmalloc-eng@...gle.com>
Subject: Re: [patch 06/19] sched/mmcid: Prevent pointless work in
 mm_update_cpus_allowed()

On Fri, Oct 17, 2025 at 07:58:53PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 17, 2025 at 02:49:29PM +0200, Thomas Gleixner wrote:
> > On Fri, Oct 17 2025 at 13:12, Peter Zijlstra wrote:
> > > On Wed, Oct 15, 2025 at 07:29:34PM +0200, Thomas Gleixner wrote:
> > >
> > >> +	if (!mm || READ_ONCE(mm->mm_cid.nr_cpus_allowed) == nr_cpu_ids)
> > >>  		return;
> > >
> > > FWIW this doesn't work on architectures that change their
> > > cpu_possible_mask around (eg. Power).
> > 
> > No. Power does not change it after boot either. Half of the kernel would
> > explode if that'd be the case.
> 
> Power very much does changes cpu_possible_mask; it doesn't change
> nr_cpu_ids. Anyway, the point is that a full mask won't be nr_cpu_ids.

Gah, bad memories, it is cpu_present_mask they change.

> Same is true when you offline a CPU come to think of it.
> 
> Same is true if the cpumask is sparse.
> 
> Anyway, just saying, checking against nr_cpu_ids might not be the best
> shortcut here.

Put another way, nr_cpus_allowed == nr_cpu_ids only work when none of
the masks involved have holes. The moment anything {possible, present,
online} has holes in, it goes sideways.