Re: [PATCH 07/11] 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] Woken proxy donors can be migrated while still referenced by `rq->donor`, causing data corruption.
- [High] Blocked proxy donors are enqueued to the tail of the local DSQ, defeating priority inheritance and bypassing SCX_ENQ_HEAD for preempted tasks with remaining slice.
--

--- Patch [7]: [PATCH 07/11] sched_ext: Handle blocked donor migration with proxy execution ---
commit e2d80964c94aa96c6517c0aa914235417a9eb814
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. This patch ensures that
active donors are not migrated by the BPF scheduler while the source
runqueue still references them. It also keeps blocked donors on the local
dispatch queue when they are put so they remain visible to the proxy pick
path.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 4af2a7a651b9f..92ab74547b693 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
> @@ -2443,6 +2443,10 @@ static bool task_can_move_from_locked_rq(struct scx_sched *sch,
>  	if (task_on_cpu(src_rq, p))
>  		return false;
>  
> +	/* Don't move a donor while its source rq still references it. */
> +	if (p->is_blocked && rcu_access_pointer(src_rq->donor) == p)
> +		return false;
> +

[Severity: High]
Does checking p->is_blocked here leave a race window where the task can be
migrated while still referenced by src_rq->donor?

If the mutex is unlocked, waking up the donor task clears its blocked state
via ttwu_do_wakeup(). If the lock owner is still running and src_rq hasn't
rescheduled yet, src_rq->donor will still point to the task.

When the BPF scheduler picks the task for migration, this check might
erroneously pass because p->is_blocked is now 0. If the task is transferred
to dst_rq, a subsequent update_curr_scx() could modify p->scx.slice while
holding src_rq's lock, racing with dst_rq which now owns the task.

Should this only check rcu_access_pointer(src_rq->donor) == p to prevent
the race?

>  	return task_can_run_on_remote_rq(sch, p, dst_rq, enforce);
>  }

[ ... ]

> @@ -3092,6 +3096,22 @@ 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.
> +		 */
> +		if (p->is_blocked) {
> +			scx_dispatch_enqueue(sch, rq, &rq->scx.local_dsq, p, 0);
> +			goto switch_class;
> +		}
> +

[Severity: High]
Does passing 0 as the enqueue flag here put the blocked donor at the tail
of the local DSQ instead of the head?

When a lock owner running on behalf of a blocked donor is preempted, this
code unconditionally uses 0 and skips the remaining slice check via the
goto. Enqueuing with flag 0 places the donor at the tail of the built-in
FIFO local DSQ instead of the head (SCX_ENQ_HEAD).

Could this cause priority inversion, as any tasks previously dispatched to
the local DSQ would run before the lock owner can resume, even if the
preempted donor still has slice remaining?

>  		/*
>  		 * If @p has slice left and is being put, @p is getting

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