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

Prakash Sangappa
2025-09-23T01:02:51Z

> On Sep 22, 2025, at 7:09 AM, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
>
> On 2025-09-19 13:30, Prakash Sangappa wrote:
>>> On Sep 13, 2025, at 6:02 AM, Thomas Gleixner <tglx@linutronix.de> 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.

Yes that is correct. Additional state will be required to track if slice extension
was requested in that context.

-Prakash

>
> Thoughts ?
>
> Thanks,
>
> Mathieu
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com