linux-kernel - Re: [patch V3 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: <4c8e32a0-aabd-4690-9bc6-e6a912874184@efficios.com>
Date: Fri, 31 Oct 2025 15:17:24 -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 20/20] sched/mmcid: Switch over to the new mechanism

On 2025-10-31 12:57, Thomas Gleixner wrote:
> On Thu, Oct 30 2025 at 12:07, Mathieu Desnoyers wrote:
>> On 2025-10-29 09:09, Thomas Gleixner wrote:
>>
>>> @@ -10702,10 +10758,43 @@ void sched_mm_cid_exit(struct task_struc
>>>    
>>>    	if (!mm || !t->mm_cid.active)
>>>    		return;
>>> +	/*
>>> +	 * Ensure that only one instance is doing MM CID operations within
>>> +	 * a MM. The common case is uncontended. The rare fixup case adds
>>> +	 * some overhead.
>>> +	 */
>>> +	scoped_guard(mutex, &mm->mm_cid.mutex) {
>>
>> When exiting from a mm where mm->mm_cid.users == 1 (read with
>> READ_ONCE()), can we do this without holding the mutex as an
>> optimization ?
> 
> What's the optimization in that case? The mutex is uncontended and the
> extra instructions for taking and releasing it are so trivial that you
> can't measure it at all.

Fair enough.

> But aside of that this might race against a scheduled work which was
> initiated by mm_update_cpus_allowed(). So keeping it strictly serialized
> makes the code simple and race free :)

OK!

With the "eventally" -> "eventually" nit fixed:

Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>

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