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

[Jihan LIN <linjh22s@gmail.com>]

On 9/21/26 12:51 PM, K Prateek Nayak wrote:
> On 9/17/2026 9:06 PM, Peter Zijlstra wrote:
>>>> 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.
> Ack!
> 
> One way to do that is by setting the "p->blocked_on" to -1 when
> find_proxy_task() detects a chain and then clear the "p->is_blocked"
> making it runnable.
> 
> Once the task exits out of schedule_preempt_disabled() and grabs the
> wait_lock, we can check the "p->blocked_on" to return -EDEADLK / stop
> proxy and fully block the task.

This approach could reuse the owner walk, which sounds useful for
avoiding an extra chain walk in the contended futex path.

That said, checking for deadlocks before sleeping would also be more
similar with PI futexes, and extra walk might be worth the cost if the
last lock attempt can simply return -EDEADLK to userspace.


Best regards,
Jihan