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

[Hui Su]

> Use the rq pick sequence as a per-walk marker. Mark each task visited by
> the current walk. If the walk sees the same marker again, break the cycle
> by clearing blocked_on at the detection point and deactivating that task.
>
> The marker is only consumed while holding rq->lock. Clear it when a task is
> activated, so stale state from an earlier pick or another rq is not carried
> into the next queued lifetime.

I have been experimenting with a different trade-off for the same cycle
detection problem. I sent it as a separate RFC so it can be reviewed
independently from the sequence-marker approach:

https://lore.kernel.org/lkml/20260914165455.2126134-1-sh_def@xxxxxxx/

The Online Brent version keeps the cycle-detection state local to the real
owner walk. It does not add state to task_struct or struct rq, and it does
not require activation-time marker reset. The cycle detector reuses the
owner resolution performed by the real walk instead of adding a separate
preflight traversal.

The trade-off is that Brent may detect a cycle only after the walk has
temporarily closed the blocked_donor cycle. In the tested natural recovery
path, the selected cycle member reached mutex_unlock() with blocked_donor
already cleared. A validation-only forced-stale test also confirmed that
the existing blocked_on revalidation rejects a stale handoff. I do not
claim that these tests cover every possible scheduling interleaving.

The RFC includes a comparison against this v5 implementation on the same
base, configuration, KVM setup, and staged testcase. The normal acyclic
find_proxy_task() timings were comparable in the tested depths; the main
design question is whether avoiding persistent task/rq visitation state and
its activation lifecycle is worth accepting the transient backlink window.

Thanks for the v5 implementation and the detailed discussion.