Re: [PATCH 05/14] sched: Add sched_ext hooks for proxy execution

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Low] The comment explaining the `should_block` argument for `try_to_bloc=
k_task()` does not reflect the newly added `!scx_allow_proxy_exec(prev)` co=
ndition.
--

--- Patch [5]: [PATCH 05/14] sched: Add sched_ext hooks for proxy execution=
 ---
commit 273c97aa298de804b9f343db4905abce55a2409e
Author: Andrea Righi <[email protected]>

sched: Add sched_ext hooks for proxy execution

This commit introduces scx_allow_proxy_exec(), scx_proxy_donor_start(),
and scx_proxy_resolved() to observe proxy execution splits. It adds their
call sites in __schedule() as empty preparatory stubs for sched_ext.

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 66e9ba50f5639..c9d77b1e2fdc7 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
[ ... ]
> @@ -7172,7 +7172,7 @@ static void __sched notrace __schedule(int sched_mo=
de)
>  		 * 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));

[Severity: Low]
This isn't a bug, but should the comment directly above this call be updated
to reflect the new logic?

The comment explicitly states that only task_is_blocked() is passed as the
argument to keep mutex-blocked tasks on the runqueue, but this patch adds
scx_allow_proxy_exec(prev) to the condition without updating the explanatio=
n.

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260725160513.5747=
[email protected]?part=3D5