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 3 potential issue(s) to consider:
- [High] Blocked donors are enqueued at the tail of the local DSQ, causing priority inversion.
- [High] Migrated blocked donors are routed to the BPF scheduler, breaking proxy execution visibility.
- [Medium] Spurious zero-slice warning triggered for blocked proxy donors.
--

--- Patch [7]: [PATCH 07/11] sched_ext: Handle blocked donor migration with proxy execution ---
commit 9cd5cbb0243a316aab34614eb668cef59ac84d98
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
allows normal sched_ext migration of blocked donors unless the donor
is active on its rq, and keeps blocked donors on the local DSQ when
they are put.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 0d2f34c79083f..abf99c582eee1 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
[ ... ]
> @@ -2395,6 +2395,19 @@ static bool task_can_run_on_remote_rq(struct scx_sched *sch,
>  	if (task_on_cpu(task_rq(p), p))
>  		return false;
>  
> +	/*
> +	 * A blocked donor may be moved normally to select a new callback rq.
> +	 * set_task_cpu() updates wake_cpu and makes the destination rq its new
> +	 * callback home, even if the donor was previously proxy-migrated.
> +	 *
> +	 * Don't move an active donor while the source rq still references it for
> +	 * scheduling and accounting. The migration can be retried after the donor
> +	 * is switched out.
> +	 */
> +	if (p->is_blocked &&
> +	    rcu_access_pointer(task_rq(p)->donor) == p)
> +		return false;
> +

[Severity: High]
When a blocked donor is migrated, is there a risk it gets routed to the BPF
scheduler instead of the local DSQ?

If a blocked donor is migrated via sched_setaffinity(), set_task_cpu() migrates
it and calls enqueue_task_scx() -> scx_do_enqueue_task() on the destination CPU.

Since there doesn't appear to be a check for p->is_blocked in the enqueue path,
the donor would be handed to the BPF scheduler's ops.enqueue callback.

Could the BPF scheduler then place the donor into a user or global DSQ,
violating the requirement that the donor remain immediately visible on the local
DSQ? This could cause the proxy lock owner to starve until the BPF scheduler
arbitrarily decides to dispatch the donor.

>  	/*
>  	 * If @p has migration disabled, @p->cpus_ptr is updated to contain only
>  	 * the pinned CPU in migrate_disable_switch() while @p is being switched
[ ... ]
> @@ -3081,6 +3094,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);

[Severity: High]
Does enqueuing with enq_flags = 0 place the blocked donor at the tail of the
local DSQ?

If there are other tasks already in the local DSQ (for example, dispatched by
the BPF scheduler), the donor won't be picked by pick_task_scx() until all
preceding tasks are drained.

Since proxy execution requires pick_next_task() to return the donor before
find_proxy_task() can run the lock owner, will this delay the lock owner's
execution and cause unbounded priority inversion?

Should this use SCX_ENQ_HEAD instead?

[Severity: Medium]
Will this trigger a spurious zero-slice warning if the blocked donor has
consumed its time slice?

When a blocked proxy donor consumes its time slice, task_tick_scx() calls
resched_curr() to preempt it. put_prev_task_scx() will place the donor here
directly into the local DSQ with p->scx.slice == 0.

When do_pick_task_scx() later picks it via first_local_task(), will the
unlikely(!p->scx.slice) check hit and trigger the KERN_WARNING, permanently
setting sch->warned_zero_slice to true? This would break a useful diagnostic
designed to catch BPF scheduler bugs, causing unnecessary kernel log pollution
and masking legitimate zero-slice issues.

> +			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/20260715205622.276220-1-arighi@nvidia.com?part=7