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

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, Dec 16 2025 at 09:36, Mathieu Desnoyers wrote:
> On 2025-12-15 13:24, Thomas Gleixner wrote:
> [...]
>> +The thread has to enable the functionality via prctl(2)::
>> +
>> +    prctl(PR_RSEQ_SLICE_EXTENSION, PR_RSEQ_SLICE_EXTENSION_SET,
>> +          PR_RSEQ_SLICE_EXT_ENABLE, 0, 0);
>
> Although it is not documented, it appears that a thread can
> also use this prctl to disable slice extension.

Obviously. Controls are supposed to be symmetrical.

> How is it meant to compose once we have libc trying to use slice
> extension internally and the application also using it or wishing to
> disable it, unaware that libc is also trying to use it ?

Tons of prctls have the same "issue". What's so special about this?

> Applications are composed of various libraries, each of which may want

I'm well aware of that fact.

> to use the feature. It's unclear to me how the per-thread slice
> extension enable/disable state fits in this context. Unless we address
> this, it will become either:
>
> - Owned and used by a single library, or
>
> - Owned and used by the application, unavailable to libraries.

The prctl allows you to query the state, so all parties can make
informed decisions. It's not any different from other mechanisms, which
require coordination between different parts.

> This goes against the design goals of RSEQ features.

These goals are documented where?

What I've seen so far at least from the implementation is that it aims
to enable the maximum amount of features, aka. overhead, unconditionally
even if nothing uses them, e.g. CID.

Your vision/goal of RSEQ being useful everywhere simply does not match
the reality.

As I pointed out in the previous submission, the benefits of time slice
extensions are limited. In low contention scenarios they result in
measurable regressions, so it's not the magic panacea which solves all
locking/critical section problems at once.

The idea that cobbling random libraries together in the hope that
everything goes well has never worked. That's simply a wet dream and
Java has proven that to the maximum extent decades ago. Nevertheless all
other programming models went down the same yawning abyss and everyone
expects that the kernel is magically solving their problems by adding
more abusable [mis]features.

Systems have to be designed carefully as a whole if you want to achieve
the maximum performance. That's not any different from other targets
like real-time. A real-time enabled kernel does not magically create a
real-time system.

TBH, the prctl should be the least of your worries. There are worse
problems with uncoordinated usage:

    set(REQUEST)
    ....

 -> Interrupt
      clr(REQUEST)
      set(GRANTED)

   lib1fn()
      set(REQUEST)            <- Inconsistent state

      if (a) {
            lib2fn()
              syscall()       <- RSEQ debug will kill the task....
      } else {
        ...
 -> Interrupt
                              <- RSEQ debug will kill the task....

And no, we are not going to lift this restriction because it allows
abuse of the mechanism unless we track more state and inflict more
overhead on the kernel for no good reason.

Thanks,

        tglx