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

[Jihan LIN <linjh22s@gmail.com>]

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?

Best regards,
Jihan