Re: [patch 00/12] rseq: Implement time slice extension mechanism

[Mathieu Desnoyers]

On 2025-09-19 13:30, Prakash Sangappa wrote:
> > On Sep 13, 2025, at 6:02 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> >
> > On Fri, Sep 12 2025 at 15:26, Mathieu Desnoyers wrote:
> > > On 2025-09-12 12:31, Thomas Gleixner wrote:
> > > > > 2) Slice requests are a good fit for locking. Locking typically
> > > > >      has nesting ability.
> > > > >
> > > > >      We should consider making the slice request ABI a 8-bit
> > > > >      or 16-bit nesting counter to allow nesting of its users.
> > > >
> > > > Making request a counter requires to keep request set when the
> > > > extension is granted. So the states would be:
> > > >
> > > >       request    granted
> > > >       0          0               Neutral
> > > > > 0         0               Requested
> > > > > =0        1               Granted
> >
> > Second thoughts on this.
[...]
> > If user space wants nesting, then it can do so on its own without
> > creating an ill defined and fragile kernel/user ABI. We created enough
> > of them in the past and all of them resulted in long term headaches.
>
> Guess user space should be able to handle nesting, possibly without the need of a counter?
>
> AFAICS can’t the nested request, to extend the slice, be handled by checking
> if both ‘REQUEST’ & ‘GRANTED’ bits are zero?  If so,  attempt to request
> slice extension.  Otherwise If either REQUEST or GRANTED bit Is set, then a slice
> extension has been already requested or granted.

I think you are onto something here. If we want independent pieces of
software (e.g. libc and application) to allow nesting of time slice
extension requests, without having to deal with a counter and the
inevitable unbalance bugs (leak and underflow), we could require
userspace to check the value of the request and granted flags. If both
are zero, then it can set the request.

Then when userspace exits its critical section, it needs to remember
whether it has set a request or not, so it does not clear a request
too early if the request was set by an outer context. This requires
handing over additional state (one bit) from "lock" to "unlock" though.

Thoughts ?

Thanks,

Mathieu

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