linux-kernel - Re: [patch V5 20/20] sched/mmcid: Switch over to the new mechanism

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 for Android: free password hash cracker in your pocket

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

Message-ID: <873466jekm.ffs@tglx>
Date: Sat, 22 Nov 2025 16:02:17 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Nathan Chancellor <nathan@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Peter Zijlstra
 <peterz@...radead.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>, Yury
 Norov <yury.norov@...il.com>, Shrikanth Hegde <sshegde@...ux.ibm.com>
Subject: Re: [patch V5 20/20] sched/mmcid: Switch over to the new mechanism

On Fri, Nov 21 2025 at 17:43, Nathan Chancellor wrote:
> Our CI started seeing a hang in QEMU after getting to userspace when
> booting with a single CPU (our default logic when using TCG instead of
> KVM) that I bisected to this change as commit 2635fb0f0973
> ("sched/mmcid: Switch over to the new mechanism") in -next.
>
> If I change '-smp 1' to '-smp 2', userspace runs properly. At the parent
> change, this issue does not exist but it is obviously possible that this
> change exposes a bug from earlier in the series, I did not test.

Duh. Never tested with smp 1 :(

Fix is below. Now let me stare at that num_possible_cpus() fallout.

Thanks,

        tglx
----
Subject: sched/mmcid: Ensure that per CPU threshold is > 0
From: Thomas Gleixner <tglx@...utronix.de>
Date: Sat, 22 Nov 2025 15:54:39 +0100

When num_possible_cpus() == 1 then the calculation for the threshold to
switch back from per CPU mode to per task mode results in 0, which
indicates that the per CPU mode is disabled.

Ensure that the threshold is > 0 to prevent that.

Fixes: 340af997d25d ("sched/mmcid: Provide CID ownership mode fixup functions")
Reported-by: Nathan Chancellor <nathan@...nel.org>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Closes: https://lore.kernel.org/all/20251122004358.GB2682494@ax162
---
 kernel/sched/core.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -10364,7 +10364,8 @@ static inline unsigned int mm_cid_calc_p
 	unsigned int opt_cids;

 	opt_cids = min(mc->nr_cpus_allowed, mc->users);
-	return min(opt_cids - opt_cids / 4, num_possible_cpus() / 2);
+	/* Has to be at least 1 because 0 indicates PCPU mode off */
+	return max(min(opt_cids - opt_cids / 4, num_possible_cpus() / 2), 1);
 }

 static bool mm_update_max_cids(struct mm_struct *mm)