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: <87tszfrov4.ffs@tglx>
Date: Fri, 31 Oct 2025 17:57:03 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 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 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.

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 :)

Thanks,

        tglx