Google floats stealable PING futexes for Linux

Suleiman Souhlal of Google has proposed an RFC series adding FUTEX_PING, a new priority-inheritance futex type meant for workloads that want PI-like behavior without classic PI futex strictness.

PING futexes (PI Next Generation, a name credited to Steven Rostedt) differ from FUTEX_*_PI in two ways. Contending lockers may steal the lock from the top waiter instead of always blocking behind a strict handoff, so a lock take need not become a scheduling event. Internally they use proxy execution rather than rtmutexes, which is intended to give priority inheritance to fair tasks as well as realtime ones. After repeated steals, the design forces a non-stealable handoff so waiters are not starved. Userspace is expected to store the owner TID as with PI futexes; the kernel may leave the waiters bit set with an empty TID, and a locker may notice that state and steal without a syscall.

Scheduler maintainer Peter Zijlstra called the work premature. He pointed at earlier futex PI efforts and restated the longer goal of folding rt_mutex into ordinary mutexes so existing FUTEX_*_PI paths would pick up the desired behavior without a parallel ABI. "I'm thinking all of this is way premature," he wrote.

Jihan Lin separately reported that a simple userspace deadlock on two PING futexes can hang the kernel: both tasks end up blocked on each other with proxy-donor state set, and proxy-task lookup can walk the cycle under the runqueue lock. He asked for cycle handling or rtmutex-style deadlock detection. K Prateek Nayak pointed at related deadlock-detection work already posted.

The series is still RFC-quality, with noted open issues around spinning limits and ownership fixups when userspace steals across task exit.