Re: [PATCH 07/10] sched_ext: Delegate proxy donor admission to BPF schedulers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Blocked proxy donors can bypass admission checks and transition into ext_sched_class while remaining queued during PI de-boost.
--

--- Patch [7]: [PATCH 07/10] sched_ext: Delegate proxy donor admission to BPF schedulers ---
commit 1b08b364547eb25f8929e3f17ff8248b2a3685d6
Author: Andrea Righi <arighi@nvidia.com>

    sched_ext: Delegate proxy donor admission to BPF schedulers
    
    Proxy execution keeps a blocked donor runnable so its scheduling context
    can execute the mutex owner. Dispatching sched_ext donors on a local
    DSQ bypasses the BPF scheduler ordering policy and can give donors
    more CPU priority than intended to perform the proxy execution handoff.

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

[ ... ]

> @@ -2887,18 +2949,12 @@ static void put_prev_task_scx(struct rq *rq, struct task_struct *p,
>  		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.
> +		 * Mutex-blocked donors only stay queued when their BPF scheduler
> +		 * enables %SCX_OPS_ENQ_BLOCKED, so always delegate their admission.
>  		 */
>  		if (p->is_blocked) {
> -			scx_dispatch_enqueue(sch, rq, &rq->scx.local_dsq, p, 0);
> +			WARN_ON_ONCE(!(sch->ops.flags & SCX_OPS_ENQ_BLOCKED));

[Severity: High]
Can a blocked proxy donor bypass admission checks and transition into
ext_sched_class while remaining queued during a PI de-boost?

If a task whose normal policy is SCHED_EXT acquires a mutex and is boosted
to RT priority via rt_mutex_setprio() (because a higher-priority RT task
blocked on it), it might subsequently block on a second mutex, becoming a
blocked donor.

When the higher-priority task gives up the first mutex or is killed, the
donor is de-boosted. In rt_mutex_setprio(), the task's policy is set back
to SCHED_EXT:

kernel/sched/core.c:rt_mutex_setprio() {
    ...
	prev_class = p->sched_class;
	next_class = __setscheduler_class(p->policy, prio);

	if (prev_class != next_class)
		queue_flag |= DEQUEUE_CLASS;

	scoped_guard (sched_change, p, queue_flag) {
    ...
}

Because this doesn't invoke scx_prepare_setscheduler() or
sched_proxy_block_task(), wouldn't the blocked task remain queued on the
runqueue? This could pass the blocked task to a BPF scheduler that does
not have SCX_OPS_ENQ_BLOCKED enabled, triggering this WARN_ON_ONCE.

> +			scx_do_enqueue_task(rq, p, 0, -1);
>  			goto switch_class;
>  		}
>

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