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

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Dec 19, 2025 at 12:21:30AM +0100, Thomas Gleixner wrote:
> 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?

So I've read this whole thread, and I'm with Thomas on this.

Yes this interface has sharp edges, but I don't think anything here
makes a case for adding more complexity.

As Thomas already stated; the very worst possible outcome is that slice
extensions are always denied -- this is a performance issue, not a
correctness issue.

To me it really reads like: Doctor, it hurts when I hit my hand with a
hammer.