Re: [PATCH 01/10] sched/core: Drop mutex locks before proxy rescheduling

[John Stultz]

On Fri, Jul 10, 2026 at 1:39 AM Andrea Righi <arighi@xxxxxxxxxx> wrote:
>
> find_proxy_task() can call proxy_resched_idle() while holding a mutex
> wait_lock and the blocked task lock. Guard cleanup does not run until
> after the return expression is evaluated.
>
> proxy_resched_idle() invokes scheduling-class callbacks through
> put_prev_set_next_task(). Calling those callbacks with the mutex locks
> held prevents them from safely inspecting the proxy chain, as doing so
> may require acquiring the same locks.
>
> This is a preparatory change to support proxy execution in sched_ext. It
> leaves the guard scope before calling proxy_resched_idle() so sched_ext
> callbacks can safely inspect the proxy chain.

Thanks again for sending these out!

So, I wanted to understand more the importance of the sched_ext logic
being able to inspect the proxy chain?

I sort of roughly understand the argument that some sched_ext
schedulers may not want to keep blocked tasks on the rq (effectively
what the "Delegate proxy donor admission to BPF schedulers" patch
does), but that doesn't require deep inspection.

This change seems to be needed for "Add proxy destination query
kfuncs", where the commit message sounds reasonable, but as I think
more on it, it doesn't look correct (I'll comment more on the patch),
and I'm still confused a bit as to the purpose.

So can you describe the premise and a bit more detail as to why this
is important?

thanks
-john