Re: [PATCH v5] sched/proxy_exec: Detect cycles in proxy walks

[Xiaomi]

Hey John,

Thanks for the reply, and agreed that the proxy futex work makes this
urgent rather than a theoretical edge case.

I tested the "deactivate the donor" idea on v31 (7.2-rc4, with the
sleeping_owner / blocked_on_lock rework), using a kernel-mutex reproducer
with a tail+cycle: D -> A -> B -> C -> A, where D waits on A but is not
in the cycle.

  deactivate p (v5):      1 detection, stable
  deactivate owner:       1 detection, stable
  deactivate donor:       unstable - 4 runs gave 1 / hang / 1 / 2

When the picked donor is D (outside the cycle), deactivating it leaves
the A->B->C->A cycle intact, so the next pick_again re-walks it and can
hang again. At detection time p and owner are always cycle members (the
check only fires once owner is already marked); the donor is only
guaranteed to be blocked.

So I'd rather keep deactivating the detection point, or switch to owner
if that reads better, but not the donor.

You're right that after one node is deactivated, the remaining blocked
tasks still get enqueued one at a time (N-1 for an N-node cycle). If
futex makes long cycles common, doing the whole blocked_donor chain in
one pass like proxy_migrate_task() would be the real win - I can
prototype that as a follow-up.

-zhidao