linux-kernel - Re: [patch V2 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: <87ldkwwwqb.ffs@tglx>
Date: Mon, 27 Oct 2025 09:54:36 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>, LKML
 <linux-kernel@...r.kernel.org>, linuxppc-dev
 <linuxppc-dev@...ts.ozlabs.org>
Cc: 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>, Madhavan
 Srinivasan <maddy@...ux.ibm.com>
Subject: Re: [patch V2 16/20] sched/mmcid: Provide new scheduler CID mechanism

On Mon, Oct 27 2025 at 10:41, Shrikanth Hegde wrote:
> On 10/22/25 6:25 PM, Thomas Gleixner wrote:
>> The MM CID management has two fundamental requirements:
>> 
>>    1) It has to guarantee that at no given point in time the same CID is
>>       used by concurrent tasks in userspace.
>> 
>>    2) The CID space must not exceed the number of possible CPUs in a
>>       system. While most allocators (glibc, tcmalloc, jemalloc) do not
>>       care about that, there seems to be at least some LTTng library
>>       depending on it.
>> 
>> The CID space compaction itself is not a functional correctness
>> requirement, it is only a useful optimization mechanism to reduce the
>> memory foot print in unused user space pools.
>> 
>
> Just wondering, if there is no user space request for CID, this whole mechanism
> should be under a static check to avoid any overhead?

The problem is that CID has been introduced unconditionally with RSEQ
and there is no mechanism to opt-in. So we could go and change the ABI,
but as you know that's generally frowned upon.

I thought about adding a static key, but that'd be systemwide and
would probably required to be opt-out for the same reason.

>> +static inline unsigned int mm_get_cid(struct mm_struct *mm)
>> +{
>> +	unsigned int cid = __mm_get_cid(mm, READ_ONCE(mm->mm_cid.max_cids));
>> +
>> +	for (; cid == MM_CID_UNSET; cpu_relax())
>
> This triggers an compile error on ppc64le.
>
> In file included from ./include/vdso/processor.h:10,
>                   from ./arch/powerpc/include/asm/processor.h:9,
>                   from ./include/linux/sched.h:13,
>                   from ./include/linux/sched/affinity.h:1,
>                   from kernel/sched/sched.h:8,
>                   from kernel/sched/rq-offsets.c:5:
> kernel/sched/sched.h: In function ‘mm_get_cid’:
> ./arch/powerpc/include/asm/vdso/processor.h:26:9: error: expected expression before ‘asm’
>     26 |         asm volatile(ASM_FTR_IFCLR(                                     \
>        |         ^~~
> kernel/sched/sched.h:3615:37: note: in expansion of macro ‘cpu_relax’
>   3615 |         for (; cid == MM_CID_UNSET; cpu_relax())
>

Duh. Did not notice because x86 implements cpu_relax() as a static
inline while PPC has it as a plain macro define. Let me move it out of
the for() then.

Thanks,

        tglx