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

[K Prateek Nayak <kprateek.nayak@amd.com>]

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/

-- 
Thanks and Regards,
Prateek