Re: [patch V6 01/11] rseq: Add fields and constants for time slice extension

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-01-13 18:45, Florian Weimer wrote:
> * Thomas Gleixner:
> 
>> I'm not completely opposed to make it process wide. For threads created
>> after enablement, that's trivial because that can be done when the per
>> thread RSEQ is registered. But when it gets enabled _after_ threads have
>> been created already then we need code to chase the threads and enable
>> it after the fact because we are not going to query the enablement in
>> curr->mm::whatever just to have another conditional and another
>> cacheline to access.
> 
> In glibc, we make sure that the registration for restartable sequences
> happens before any user code (with the exception of IFUNC resolvers) can
> run.  This includes code from signal handlers.  We started masking
> signals on newly created threads for this reason, to make these
> partially initialized states unobservable.
> 
> It's not clear to me what the expected outcome is.  If we ever want to
> offer deadline extension as a mutex attribute (for example), then we
> have to switch this on at process start unconditionally because we don't
> know if this new API will be used by the new process (potentially after
> dlopen, so we can't even use things likely analyzing the symbol
> footprint ahead of time).
> 
>> The only option is to reject enablement when there is already more than
>> one thread in the process, but there is a reasonable argument that a
>> process might only enable it for a subset of threads, which have actual
>> lock interaction and not bother with it for other things. I'm not seeing
>> a reason to restrict the flexibility of configuration just because you
>> envision magic use cases all over the place.
> 
> Sure, but it looks like this needs a custom/minimal libc.  It's like
> repurposing set_robust_list for something else.  It can be done, but it
> has a significant cost in terms of compatibility because some
> functionality (that other libraries in the process depend on) will stop
> working.

My main concern is about the overhead of added system calls at thread
creation. I recall that doing an additional rseq system call at thread
creation was analyzed thoroughly for performance regressions at the
libc level. I would not want to start requiring libc to issue a
handful of additional prctl system calls per thread creation for no good
reason.

I don't mind that much whether we enable slice extension per
process or per thread, but what I do mind in the case of per-thread
enabling is whether the enabling scheme can be batched, so a user
enables a set of rseq features in one go, ideally at rseq registration.
This is missing with the prctl approach proposed by Thomas.

If the enabling is per-process, it's not so bad because there is
already a lot happening on exec, so I would not mind a prctl that
much, but for per-thread enabling I see the many individual system
calls as an issue we need to address.

> We need the prctl to unregister for CRIU, though, otherwise CRIU won't
> be able to use glibc directly (or would have to re-exec itself in a new
> configuration).

Good point that the unregister is needed. Which means the prctl is
probably needed then. But it does not solve the "handful of prctl
per thread creation" issue, which probably calls for something more
at the rseq system call level.

So I wonder if we could extend the rseq thread registration to also
specify a set of "features to enable" somehow ? This would still be
per-thread, but would not require additional prctl on thread creation.

Thanks Florian and Thomas for your input, this helps me corner the
issue that's nagging at me.

Thanks,

Mathieu

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