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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <a54efee6-3137-4035-8a27-b5e59f3a0ca3@linux.ibm.com>
Date: Sat, 22 Nov 2025 22:24:38 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: Thomas Gleixner <tglx@...utronix.de>,
        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>
Subject: Re: [patch V5 20/20] sched/mmcid: Switch over to the new mechanism



On 11/22/25 8:32 PM, Thomas Gleixner wrote:
> 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)


Having both patches (this patch and num_possible_cpus fix) patch was
necessary for successful boot of smp=1 on qemu.