linux-kernel - Re: [PATCH 00/30] RSEQ node id and mm concurrency id extensions

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] [day] [month] [year] [list]

Message-ID: <CANpmjNP9ApuE+FyeSPPEJZK9Q8BdY24i8xuqhTbXEQM_d_HmcQ@mail.gmail.com>
Date: Thu, 29 Feb 2024 10:31:24 +0100
From: Marco Elver <elver@...gle.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org, 
	Thomas Gleixner <tglx@...utronix.de>, "Paul E . McKenney" <paulmck@...nel.org>, 
	Boqun Feng <boqun.feng@...il.com>, "H . Peter Anvin" <hpa@...or.com>, Paul Turner <pjt@...gle.com>, 
	linux-api@...r.kernel.org, Christian Brauner <brauner@...nel.org>, 
	Florian Weimer <fw@...eb.enyo.de>, David.Laight@...lab.com, carlos@...hat.com, 
	Peter Oskolkov <posk@...k.io>, Alexander Mikhalitsyn <alexander@...alicyn.com>, 
	Chris Kennelly <ckennelly@...gle.com>, dvyukov@...gle.com
Subject: Re: [PATCH 00/30] RSEQ node id and mm concurrency id extensions

On Wed, 28 Feb 2024 at 21:01, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com> wrote:
[...]
> AFAIK the only project using the mm_cid concept I know of today is
> tcmalloc. It's very useful to scale data structures such as memory
> allocator arenas to the number of concurrently running threads
> within a process without having to rely on heuristics on the
> user-space side.
>
> I have plans to migrate LTTng-UST to per-ipc-namespace NUMA-aware
> mm_cid as well (after I get around to submit this extension into the
> Linux kernel) for user-space ring buffers over shared memory, but my
> current focus has been on pushing support for extensible RSEQ into
> GNU libc for the past year or so.
>
> We are getting there though:
>
> https://sourceware.org/pipermail/libc-alpha/2024-February/154390.html

Glad to see this!

> Once we have this key piece in place within GNU libc, it will become
> easier to extend rseq further because the libc will adapt to the extended
> feature set.
>
> Note that the overhead of the mm_cid assignment within the scheduler
> should be negligible after
> commit 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid").
>
> Another thing we've actively been working on is to get the "librseq"
> project [1] in shape so a copy the librseq headers can be integrated
> into the GNU libc project as internal header files. So basically
> librseq will become a GNU libc upstream. This will facilitate
> implementation of rseq critical section within GNU libc. One of
> the possible use-cases will be to move the GNU libc malloc
> implementation to per-mm_cid arenas.

I suppose if GNU libc malloc starts using it then usage would become
ubiquitous in no time.

> > I'm aware that TCMalloc was the inspiration for vCPUs [1], then renamed to
> > CIDs, but am wondering if other users are out there.
>
> I'd be curious to learn about those as well.
>
> I suspect that the lack of official release of librseq critical section
> helper headers may contribute to the fact that few applications use advanced
> rseq features at this point.

I guess you've answered my question, and I conclude "no known open
source usage yet". A simple search on Github or the likes also didn't
yield anything. I will go and check again in a year or so. ;-)

Thanks,
-- Marco