[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <82BDDCE0-1611-4A03-A46C-62EE844A8E70@oracle.com>
Date: Tue, 23 Sep 2025 01:01:59 +0000
From: Prakash Sangappa <prakash.sangappa@...cle.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
CC: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>,
Peter Zilstra <peterz@...radead.org>,
"Paul E. McKenney"
<paulmck@...nel.org>,
Boqun Feng <boqun.feng@...il.com>, Jonathan Corbet
<corbet@....net>,
Madadi Vineeth Reddy <vineethr@...ux.ibm.com>,
K Prateek
Nayak <kprateek.nayak@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Arnd Bergmann
<arnd@...db.de>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
Florian Weimer <fweimer@...hat.com>,
"carlos@...hat.com" <carlos@...hat.com>,
"libc-coord@...ts.openwall.com" <libc-coord@...ts.openwall.com>
Subject: Re: [patch 00/12] rseq: Implement time slice extension mechanism
> On Sep 22, 2025, at 7:09 AM, Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
>
> On 2025-09-19 13:30, Prakash Sangappa wrote:
>>> On Sep 13, 2025, at 6:02 AM, Thomas Gleixner <tglx@...utronix.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
