Re: [PATCH] sched/proxy_exec: Limit find_proxy_task() chain depth to prevent CPU hang

[zhidao su]

Hello John, Prateek,

On Tue, Apr 21, 2026 at 08:43 AM +0530, K Prateek Nayak wrote:
> As an alternate approach, when traversing blocked_on links, can we
> start deactivating the chain if we encounter rq->donor again as owner
> in find_proxy_task() loop?
>
> That way we go back to triggering the hung task detector and if someone
> has a stack that depends on it, it'll continue to work fine while also
> avoiding this lockup.

Thanks for the suggestion. I've implemented and tested this approach.

On John's point about BUG(): I agree lock cycles are a serious bug,
but deactivating the donor preserves mutex_lock_interruptible()
recovery paths and avoids a hard system stop for what could be an
application-level bug. The WARN_ONCE + hung-task splat provides
sufficient visibility.

Changes from v1:
 - Replace proxy_resched_idle() with proxy_deactivate() on both the
   depth-exceeded path and the new cycle-detected path.
   proxy_resched_idle() returns rq->idle, causing __schedule() to
   immediately re-select the same donor and re-enter find_proxy_task(),
   creating a soft loop with no forward progress. (John Stultz)
 - Add owner == donor cycle detection immediately after resolving
   owner from blocked_on. This catches A->B->...->A at the first chain
   closure; no visited set needed. (K Prateek Nayak)
 - Raise MAX_PROXY_CHAIN_DEPTH from 64 to 1024 to match rt-mutex's
   max_lock_depth. (John Stultz)

Tested with pe_cycle_kmod (two kthreads pinned to CPU 0, each holding
one mutex and trying to acquire the other, virtme-ng, CONFIG_LOCKDEP=n):

  [  109.057659] sched/pe: deadlock cycle detected, pid 154
  [  109.057687] WARNING: CPU: 0 PID: 155 at kernel/sched/core.c:7392
                 find_proxy_task+0x.../...
  ...
  [  246.820220] INFO: task pe_cycle_A:154 blocked for more than 122 seconds.
  [  246.820238] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  [  246.820358] INFO: task pe_cycle_A:154 is blocked on a mutex likely owned by task pe_cycle_B:155.
  [  246.820360] INFO: task pe_cycle_B:155 blocked for more than 122 seconds.
  [  246.820433] INFO: task pe_cycle_B:155 is blocked on a mutex likely owned by task pe_cycle_A:154.
  EXEC_DONE  (VM continued normally throughout)

cycle detection fires immediately (~1ms after deadlock forms), donor
is deactivated, hung-task detector fires after 122s as expected.

Will send v2 once this direction is confirmed.

Thanks,
zhidao su