Re: [PATCH 03/11] sched_ext: Block proxy donors across scheduler transitions

[John Stultz]

On Thu, Jul 16, 2026 at 6:23 AM Andrea Righi <arighi@xxxxxxxxxx> wrote:
>
> Proxy execution retains mutex-blocked donors on the runqueue so their
> scheduling context can execute a lock owner. sched_ext cannot safely
> retain such donors unless the BPF scheduler explicitly participates in
> their admission and ordering.
>
> Make sched_ext reject retained donors by default. Force blocked EXT
> tasks through the regular block path in schedule(), and fully deactivate
> a retained donor before sched_setscheduler(), PI de-boosting, or global
> activation moves it into the EXT class. These hooks establish the safe
> default that a later opt-in can relax.
>
> This is a preparatory change to support proxy execution with sched_ext.
>
> Signed-off-by: Andrea Righi <arighi@xxxxxxxxxx>
> ---
>  kernel/sched/core.c     |  5 ++++-
>  kernel/sched/ext/ext.c  | 44 +++++++++++++++++++++++++++++++++++++++++
>  kernel/sched/ext/ext.h  |  6 ++++++
>  kernel/sched/syscalls.c |  3 +++
>  4 files changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index e7827cffc2f0c..ddc832035854b 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7173,7 +7173,8 @@ static void __sched notrace __schedule(int sched_mode)
>                  * task_is_blocked() will always be false).
>                  */
>                 try_to_block_task(rq, prev, &prev_state,
> -                                 !task_is_blocked(prev));
> +                                 !task_is_blocked(prev) ||
> +                                 !scx_allow_proxy_exec(prev));
>                 switch_count = &prev->nvcsw;
>         }

This reminds me that since we no longer re-use try_to_block_task()
elsewhere, we can probably push the checks down into the function and
get rid of teh should_block argument.

But this is a minor cleanup for later, not an issue with this patch.

This looks good to me!
Acked-by: John Stultz <jstultz@xxxxxxxxxx>