linux-kernel - Re: [patch V3 16/20] sched/mmcid: Provide new scheduler CID 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: <45d09605-7cd4-48a5-9141-32ccd6695813@efficios.com>
Date: Thu, 30 Oct 2025 11:09:12 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
 Gabriele Monaco <gmonaco@...hat.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 V3 16/20] sched/mmcid: Provide new scheduler CID mechanism

On 2025-10-29 09:09, Thomas Gleixner wrote:
> The MM CID management has two fundamental requirements:

This explanation is duplicated verbatim between the previous
infrastructure patch and this one. I recommend keeping only
one of the two copies and adding a cross-reference in case
people are looking for details.

> @@ -130,7 +132,10 @@ struct mm_cid_pcpu {
>    * @mutex:		Mutex to serialize forks and exits related to this mm
>    */
>   struct mm_mm_cid {
> +	/* Hotpath read mostly members */
>   	struct mm_cid_pcpu	__percpu *pcpu;
> +	unsigned int		percpu;
> +	unsigned int		transit;
>   	unsigned int		max_cids;
>   	unsigned int		nr_cpus_allowed;
>   	unsigned int		users;

I'll repeat my concern about false-sharing between frequent "users"
updates and surrounding read-mostly fields.

> +
> +static __always_inline void mm_cid_schedout(struct task_struct *prev)
> +{
> +	/* During mode transitions CIDs are temporary and need to be dropped */
> +	if (likely(!cid_in_transit(prev->mm_cid.cid)))
> +		return;
> +
> +	mm_drop_cid(prev->mm, cid_from_transit_cid(prev->mm_cid.cid));
> +	prev->mm_cid.cid = MM_CID_UNSET;

I wonder why the transition from per-task to per-cpu needs to drop the
per-task CIDs. Can't we just move them to the per-cpu CID tracker
instead ? This would save us a "thundering herd" effect on the
cid mask allocation when switching from per-task to per-cpu.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com