Re: [PATCH 10/15] sched_ext: Handle proxy-exec races in remote DSQ transfers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Tasks can be permanently starved because migration-disabled state is conflated with active proxy execution, bypassing deferred work and BPF scheduler failsafes.
--

--- Patch [10]: [PATCH 10/15] sched_ext: Handle proxy-exec races in remote DSQ transfers ---
commit 4a7a0caa08e0bdff136179deb5a687b13392995f
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: Handle proxy-exec races in remote DSQ transfers

This commit handles proxy execution races during remote DSQ transfers
by re-evaluating task execution and migration-disabled states under the
source rq lock. Tasks that can no longer proceed are parked on the
source rq's reject DSQ to be re-enqueued later, maintaining placement
policies.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index b43b2834141e6..7b467b666212b 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c

[ ... ]

> @@ -2573,6 +2585,60 @@ static bool task_can_run_on_remote_rq(struct scx_sched *sch,
>  	return true;
>  }
>  
> +/*
> + * Proxy execution can change @p's execution and migration-disabled state
> + * without touching its DSQ entry or clearing holding_cpu. Check those states
> + * with @p's rq locked. Without proxy execution, the holding_cpu handshake is
> + * sufficient and this must not affect the existing migration path.
> + *
> + * A BPF-directed transfer to a remote local DSQ performs a normal task
> + * migration and thus cannot move a migration-disabled task. In contrast,
> + * proxy_migrate_task() moves only a blocked donor's scheduling context towards
> + * the mutex owner and preserves its execution home in wake_cpu. The latter is
> + * therefore allowed even when the donor is migration-disabled.
> + */
> +static bool task_move_proxy_raced(struct task_struct *p)
> +{
> +	struct rq *src_rq = task_rq(p);
> +
> +	lockdep_assert_rq_held(src_rq);
> +
> +	if (!sched_proxy_exec())
> +		return false;
> +
> +	/* @p may be rq->curr under another task's scheduling context. */
> +	if (task_on_cpu(src_rq, p))
> +		return true;
> +
> +	if (is_migration_disabled(p))
> +		return true;

[Severity: High]
Does returning true unconditionally for migration-disabled tasks conflate them
with active proxy execution? 

If a task is migration-disabled but not actively proxying, it will be rejected
with SCX_TASK_REENQ_PROXY. Since rq_owned_post_enq() skips calling
schedule_deferred_locked() for SCX_TASK_REENQ_PROXY rejects:

	if (dsq->id == SCX_DSQ_REJECT) {
		if ((p->scx.flags & SCX_TASK_REENQ_REASON_MASK) ==
		    SCX_TASK_REENQ_PROXY)
			rq->scx.flags |= SCX_RQ_PROXY_REENQ;
		else
			schedule_deferred_locked(rq);
	}

And scx_proxy_resolved() is never called for a task that isn't actively
proxying, could this leave the task permanently stranded on the reject DSQ if
the source rq is idle?

> +
> +	/* Don't move an active scheduling context off its source rq. */
> +	if (task_current_donor(src_rq, p))
> +		return true;
> +
> +	return false;
> +}

[ ... ]

> @@ -2660,6 +2740,7 @@ static struct rq *move_task_between_dsqs(struct scx_sched *sch,
>  					 struct scx_dispatch_q *dst_dsq)
>  {
>  	struct rq *src_rq = task_rq(p), *dst_rq;
> +	bool proxy_raced;
>  
>  	BUG_ON(src_dsq->id == SCX_DSQ_LOCAL);
>  	lockdep_assert_held(&src_dsq->lock);
> @@ -2667,6 +2748,13 @@ static struct rq *move_task_between_dsqs(struct scx_sched *sch,
>  
>  	if (dst_dsq->id == SCX_DSQ_LOCAL) {
>  		dst_rq = container_of(dst_dsq, struct rq, scx.local_dsq);
> +		proxy_raced = src_rq != dst_rq && task_move_proxy_raced(p);
> +		if (unlikely(proxy_raced)) {
> +			dispatch_dequeue_locked(p, src_dsq);
> +			raw_spin_unlock(&src_dsq->lock);
> +			scx_reject_task(sch, src_rq, p, enq_flags);
> +			return src_rq;
> +		}

[Severity: High]
If a BPF scheduler incorrectly attempts to migrate a migration-disabled task to
a remote local DSQ, task_move_proxy_raced() intercepts the dispatch here.

Can this prevent task_can_run_on_remote_rq() from detecting the illegal
migration and triggering scx_error(), bypassing the BPF scheduler failsafe
while leaving the task permanently starved?

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