Re: [RFC] in-kernel rseq

[David Laight <david.laight.linux@gmail.com>]

On Tue, 24 Feb 2026 08:33:23 -0500
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> On 2026-02-24 05:27, David Laight wrote:
> [...]
> > 
> > No scaling, in this case it is fine to add the rseq just before needing it.  
> 
> In all cases it is fine to set the per-task rseq pointer just before
> needing it. That's how the userspace rseq was implemented.
> 
> > But if they have to be set in advance then you start getting a long list
> > to check - I'm sure that must happen with userspace rseq?  
> 
> No, userspace declares rseq_cs descriptors in its data, and populates
> the rseq_abi->rseq_cs field (thread-local) with a pointer to that
> descriptor at the very beginning of the critical section.
> 
> So return to userspace after context switch either finds a NULL pointer
> or only needs to load from a single rseq_cs descriptor from userspace.

So all of the program has to use a single (per thread) 'rseq' structure?
And you better not try to use it in a signal handler.

I'm sure I should know the main use-case for user-space rseq.
I do remember a big problem with short-duration 'hot mutex' used for
(eg) removing work items from a linked list.
Although the 'hold time' is usually only a few instructions (so contention
is unlikely) if you get hit by an ethernet interrupt while the mutex is
held it can take milliseconds for all the softint code to complete before
the mutex is released - not good for system throughput.

	David

> 
> Thanks,
> 
> Mathieu
>