Re: [PATCH 08/12] sched_ext: Handle blocked donor migration with proxy execution

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The newly added proxy-execution handling for blocked donors in put_prev_task_scx() is unreachable for sched_ext tasks, completely breaking proxy execution for this class.
- [Medium] Blocked proxy donors are enqueued to the tail of the local DSQ instead of the head, causing priority inversion when other tasks are batched.
--

--- Patch [8]: [PATCH 08/12] sched_ext: Handle blocked donor migration with proxy execution ---
commit 6380b59c7e35fb635b7bc11e5fa121a8296ed2b7
Author: John Stultz <jstultz@google.com>

sched_ext: Handle blocked donor migration with proxy execution

With proxy execution enabled, mutex-blocked donors stay runnable so
their scheduling context can execute the lock owner.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index a466adf8e1548..bf53f2be77f05 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
[ ... ]
> @@ -3122,6 +3126,25 @@ static void put_prev_task_scx(struct rq *rq, struct task_struct *p,
>  	if (p->scx.flags & SCX_TASK_QUEUED) {
>  		set_task_runnable(rq, p);
>  
> +		/*
> +		 * Mutex-blocked donors stay queued on the runqueue under proxy
> +		 * execution, but the donor never runs as itself, proxy-exec
> +		 * walks the blocked_on chain on the next __schedule() and runs
> +		 * the lock owner in its place.
> +		 *
> +		 * Put the donor on the local DSQ directly so pick_next_task()
> +		 * can still see it. find_proxy_task() will either run the chain
> +		 * owner or deactivate the donor so the wakeup path can return it
> +		 * and let BPF make a new dispatch decision once it is unblocked.
> +		 *
> +		 * This is preparatory code: a later patch will delegate blocked-donor
> +		 * admission to the BPF scheduler.
> +		 */
> +		if (p->is_blocked) {
> +			scx_dispatch_enqueue(sch, rq, &rq->scx.local_dsq, p, 0);

[Severity: High]
Is this newly added proxy execution handling for blocked donors reachable for
sched_ext tasks?

When a sched_ext task blocks on a mutex, try_to_block_task() checks
!task_is_blocked(prev) || !scx_allow_proxy_exec(prev) to decide if it
should be fully dequeued. scx_allow_proxy_exec() unconditionally returns
false for ext_sched_class:

kernel/sched/ext/ext.c:scx_allow_proxy_exec() {
        return p->sched_class != &ext_sched_class;
}

Since should_block evaluates to true, the task is passed to block_task(),
which unconditionally dequeues it via dequeue_task_scx(). Dequeuing clears
SCX_TASK_QUEUED.

When put_prev_task_scx() is then called by __schedule() during the task
switch, the task is no longer queued (p->scx.flags & SCX_TASK_QUEUED is
false), meaning this entire block of newly added proxy donor retention
logic seems to be bypassed as dead code.

[Severity: Medium]
Will enqueuing the blocked proxy donor to the tail of the local DSQ cause a
priority inversion?

If the BPF scheduler has previously dispatched a batch of tasks to the local
DSQ, using 0 (tail enqueue) places the blocked donor behind them.
pick_next_task() will pop and execute the batched tasks before the donor,
delaying the execution of the lock owner.

Should this use SCX_ENQ_HEAD instead, similar to slice-preempted tasks, so
the lock owner can execute immediately to release the contended mutex?

> +			goto switch_class;
> +		}
> +
>  		/*
>  		 * If @p has slice left and is being put, @p is getting
>  		 * preempted by a higher priority scheduler class or core-sched

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