Re: [RFC PATCH 07/12] futex: Make FUTEX_*_PING use Proxy Execution.

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Sep 17, 2026 at 08:09:34PM +0530, K Prateek Nayak wrote:
> On 9/17/2026 6:48 PM, Jihan LIN wrote:
> > [You don't often get email from linjh22s@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > Hi Suleiman,
> > 
> > Thanks for your RFC series.
> > 
> >> diff --git a/kernel/futex/ping.c b/kernel/futex/ping.c
> >> index ebcd3c4a7793..689f149f7150 100644
> >> --- a/kernel/futex/ping.c
> >> +++ b/kernel/futex/ping.c
> >> @@ -370,6 +370,9 @@ int futex_lock_ping(u32 __user *uaddr, unsigned int flags, ktime_t *time,
> >>
> >>               queued = false;
> >>               while (1) {
> >> +                     set_task_blocked_on(current, &q.ping_state->ping_mutex,
> >> +                                         BO_T_PING_FUTEX);
> >> +
> >>                       set_current_state(TASK_INTERRUPTIBLE|TASK_FREEZABLE);
> >>                       if (!queued) {
> >>
> > 
> > A userspace deadlock seems to turn into a kernel lockup.
> > Consider threads A and B on CPU0, unlocked PING futexes F1 and F2, with
> > the following ordering:
> > 
> >   A: CAS(F1, gettid(A))
> >   B: CAS(F2, gettid(B))
> >   A: futex(&F2, FUTEX_LOCK_PING) <-- T1
> >   B: futex(&F1, FUTEX_LOCK_PING) <-- T2
> > 
> > Since futex_lock_ping_atomic() only checks self-lock, both tasks end
> > up blocked on each other after T2. And task_is_blocked() is true for both
> > tasks, try_to_block_task() would keep them on runqueue with
> > tsk->is_blocked set.  So if pick_next_task() picks A or B,
> > find_proxy_task() will stuck walking on A -> B -> A -> ... with rq->lock.
> > 
> > Could we handle cycles in find_proxy_task(), or add a chain walk for
> > deadlock detection for FUTEX_LOCK_PING like rtmutex?
> 
> https://lore.kernel.org/lkml/20260714152220.4046736-1-soolaugust@gmail.com/

Ah yes, that thing. I would suggest to still have a hard-coded limit,
but perhaps in addition to the sequence mark.

Without a hard-coded limit, userspace is free to create chains of
arbitrary length. This should be discouraged :-)

Also, we need to be able to return -EDEADLK to userspace.

Ideally userspace gets to have an extra graph walk on block though, and
not rely on pick time sanity checks.