Re: [PATCH v2] sched/proxy_exec: Break cyclic proxy chains by deactivating blocked tasks

[soolaugust@gmail.com]

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.