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

[sashiko-bot@kernel.org]

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_block_task()` does not reflect the newly added `!scx_allow_proxy_exec(prev)` condition.
--

--- Patch [5]: [PATCH 05/14] sched: Add sched_ext hooks for proxy execution ---
commit 273c97aa298de804b9f343db4905abce55a2409e
Author: Andrea Righi <arighi@nvidia.com>

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_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));

[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 explanation.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260725160513.57477-1-arighi@nvidia.com?part=5