Re: [PATCH 06/10] sched_ext: Handle blocked donor migration with proxy execution

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional enqueue of blocked proxy donors to the tail of the local DSQ causes priority inversion, escapes BPF scheduling quotas, and triggers kernel warnings.
--

--- Patch [6]: [PATCH 06/10] sched_ext: Handle blocked donor migration with proxy execution ---
commit dce762461a67fc44d618711fc879bc542af59027
Author: John Stultz <[email protected]>

sched_ext: Handle blocked donor migration with proxy execution

This commit enables sched_ext to handle the migration of blocked donors
under proxy execution. It allows normal migration of non-active blocked
donors and ensures they remain on the local DSQ when put, maintaining
visibility for the proxy pick path.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 840d61ee24e74..1f05f91e55192 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c

[ ... ]

> @@ -2873,6 +2886,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]
By unconditionally passing 0 (tail enqueue) to scx_dispatch_enqueue() for
preempted proxy donors, does this cause a priority inversion by defeating
proxy execution priority inheritance?

Furthermore, if a donor task exhausts its slice and is preempted here, does
this bypass the do_enqueue_task() fallback path? It seems zero-slice donors
would get trapped in the local DSQ instead of returning to the BPF
scheduler via ops.enqueue(), potentially triggering a kernel warning in
do_pick_task_scx() and artificially granting an unmonitored slice_dfl refill
that bypasses BPF quotas.

> +			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/[email protected]?part=6