linux-kernel - Re: [patch V3 15/20] sched/mmcid: Introduce per task/CPU ownership infrastrcuture

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: <f2c2c954-0991-4974-9ae5-6cf14314781d@efficios.com>
Date: Thu, 30 Oct 2025 10:45:56 -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 15/20] sched/mmcid: Introduce per task/CPU ownership
 infrastrcuture

On 2025-10-29 09:09, Thomas Gleixner wrote:

Subject typo:

infrastrcuture -> infrastructure

> 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.

About (2), it's not at the moment specifically about LTTng. The librseq project
depends on this limit within its per-cpu allocator:

https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/src/rseq-mempool.c#n970

librseq is not used by LTTng right now. It is a library that was initially sitting
in the rseq kernel selftests, and I'm planning to eventually remove the code
duplication and have the rseq selftests just depend on librseq.

We are discussing with the BIND9 name server developers and they are interested
to start using the librseq per-cpu allocator within their project as well.

The LTTng userspace tracer will only be able to use the concept of "concurrency ID"
when/if we implement support for a "per-ipc-namespace concurrency id domain". We
basically need to have per-CID indexing of a per-cpu data structure over a shared
memory mapping shared across many processes within a namespace (IPC namespace seems
like a plausible candidate for this). So we'd have two "concurrency id" fields in
struct rseq: mm_cid (per-process CID), and ipc_ns_cid (per-namespace CID).

> milliseconds later when the next task changes it's affinity.

it's -> its

> penalazing everyone else.

penalize

> That allows to check for ownership trivialy and provides a simple check for

trivially

> + * MM_CID_ONCPU bit set. During transitioning from CPU to task ownership

transitioning -> transition

> + * actualy handed over to user space in the RSEQ memory.

actually

Thanks,

Mathieu

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