Re: [RFC PATCH 00/12] FUTEX_PING: A stealable futex using Proxy Execution.

[Peter Zijlstra]

On Fri, Sep 18, 2026 at 03:07:56PM +0900, Suleiman Souhlal wrote:
> On Thu, Sep 17, 2026 at 5:58 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > On Thu, Sep 17, 2026 at 04:33:24AM +0000, Suleiman Souhlal wrote:
> > > Hello,
> > >
> > > This patch series adds a new type of PI futexes, PI Next Generation,
> > > or PING (name coined by Steven Rostedt) (but other name suggestions
> > > are welcome!), that differs from classic PI futexes in that they can
> > > be stolen from the top waiter, and use Proxy Execution instead of
> > > rtmutexes internally.
> > >
> > > The reason to allow the futexes to be stolen is that with classic PI
> > > futex's strict handoff to the top waiter, new contending lockers are
> > > now forced to wait in queue, which means that any locking operation
> > > now becomes a scheduling event. With stealing, a contending locker has
> > > the chance of taking the lock without blocking. The longer wait time
> > > of blocked tasks can be mitigated by forcing the lock to be handed
> > > off to them in a way that can't be stolen, when they've been stolen
> > > from too much, to ensure they don't get starved.
> > >
> > > The use of Proxy Execution lets us also get Priority Inheritance for
> > > for fair tasks, which PI futexes don't really allow.
> >
> > https://patch.msgid.link/1490204338-1856-1-git-send-email-longman%40redhat.com
> 
> I was not aware of this, thanks!
> It actually seems very similar to this patchset (but much better written).
> The main functional differences that I can see from a cursory look are
> that on unlock it doesn't preserve the waiters bit, while PING does,
> and that TP futex also supports userspace rwlocks, unlike PING.
> And of course the fact that PING also uses Proxy Execution.
> So now I know that I'm not completely crazy for wanting this. :-)

Well, you all seem to be in violent disagreement with yourself. On the
one hand you call your feature Priority Inheritance Next-Gen, while at
the same time you're arguing you do NOT in fact want the strictness of
PI/RT.

You cannot have it both ways.


But yes, FUTEX_LOCK/FUTEX_UNLOCK is desirable for a fair number of
reasons, and Waiman's earlier attempt basically died because neither
Thomas nor me found time to do a proper review :-(

One of the very few things that I remember being annoyed with is that it
did handoff in the futex code, while mutex_unlock() already has this.
But other than it being a annoyance, I never had enough time to dig in
to understand if this was fixable or not.

Anyway, back then the motivation for FUTEX_LOCK was to get optimistic
spinning for 'free' by using mutex, much like how FUTEX_LOCK_PI uses
rt_mutex. These days, you'd get proxy exec as well.

But like I mentioned elsewhere, the whole futex/proxy thing needs a
deadlock detector, something we don't really need for in-kernel code,
since it is a hard requirement for kernel code not to have lock cycles
(barring ww_mutex, which will resolve them etc.). But we cannot trust
userspace to play nice.

Doing it at schedule() time is very much not ideal, this is something
much better done at block time, not least because it is the ideal
context to return -EDEADLK, but also because you but the cost of
verifying it in the right context.