Re: [PATCH v2] sched/proxy_exec: Break cyclic proxy chains by deactivating blocked tasks
From: soolaugust
Date: Tue Jul 14 2026 - 22:37:41 EST
Thanks Prateek.
> I'm not really a fan of the arbitrary MAX_PROXY_CHAIN_DEPTH.
Agreed. It was only a guard rail, not a real fix. I'll drop it in v3
and switch to a proper cycle check.
> This only catches cycles that come back to the original donor.
Right. The owner == donor check only catches cycles that include the
original donor, so it misses loops in the middle of the chain, like
your A -> B -> C -> D -> B example.
> Maybe we can use the blocked_donor backlink as a visited marker?
The basic idea makes sense, but I'd rather not overload blocked_donor.
That field is already the donor-stack backlink, and keeping it as a
plain task pointer seems easier to reason about as the proxy-exec model
grows to more primitives.
So for v3 I'll likely use an explicit per-pick seq marker instead.
> We should probably think about other lock types too.
Yes, agreed. That's another reason to keep this at the proxy
wait-for-chain level rather than make it mutex-specific. The current
tree still only has mutex-backed blocked_on, but the design is meant to
cover other blocking primitives as well.
Thanks for the review. I'll rework v3 accordingly.