Re: [RFC PATCH 1/1] sched/proxy_exec: detect cycles in proxy walks

[John Stultz]

On Mon, Sep 14, 2026 at 9:55 AM Hui Su <sh_def@xxxxxxx> wrote:
>
> Proxy execution follows blocked_on relationships to find a runnable lock
> owner. A cycle in that chain can make find_proxy_task() loop indefinitely
> while holding rq->lock.
>
> Use Brent checkpoint state directly in the real owner walk. Cycle detection
> reuses the owner resolution already performed by that walk and requires no
> separate preflight traversal. The checkpoint, power, and span state are all
> invocation-local.
>
> Keep the existing owner == p wakeup-race handling ahead of cycle detection.
> Unlike a sequence-marker approach, this adds no task_struct or runqueue
> state and requires no activation-time reset.
>
> The online walk can temporarily install a blocked_donor cycle before the
> delayed Brent detection point. In the tested recovery path, the selected
> task's blocked_donor was cleared before it resumed. A forced-stale control
> also confirmed that mutex handoff revalidates the donor's blocked_on
> relationship before consuming a backlink. Validation of this trade-off and
> comparative measurements against the sequence-marker approach are included
> in the cover letter.
>
> Signed-off-by: Hui Su <sh_def@xxxxxxx>

Hey! Thanks for sending this out and apologies for my slow response to
your patches.

This looks interesting, and with Suleiman's futex work, it becomes
more critical to include.

I think similar to what Peter already mentioned, having a max depth
counter is probably still a good idea, but it does seem like this
would catch smaller cycles earlier without much overhead.

I've included an simplified version of Zhidao Su's earlier work (using
a fixed MAX_PROXY_CHAIN_DEPTH) in my tree, but will include this as
well as an potential optimization.

thanks
-john