Re: [PATCH 06/12] sched_ext: Fix proxy-exec race in consume_remote_task()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] task_can_move_from_locked_rq() fails to check if the task is the active donor on the source runqueue under proxy execution.
--

--- Patch [6]: [PATCH 06/12] sched_ext: Fix proxy-exec race in consume_remote_task() ---
commit 681e47b7800ef6cd6756031dfb833542e391c7df
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: Fix proxy-exec race in consume_remote_task()

This patch addresses a proxy execution race where a task's state can change
without clearing holding_cpu. It introduces task_can_move_from_locked_rq()
to recheck the on-CPU and migration-disabled states after switching to the
source runqueue lock. If the state changed, the task is requeued on the
global DSQ instead of aborting the BPF scheduler.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 30d5965d09108..b5fd91d9bca4f 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c

[ ... ]

> @@ -2432,6 +2429,28 @@ 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.
> + */
> +static bool task_can_move_from_locked_rq(struct task_struct *p)
> +{
> +	struct rq *src_rq = task_rq(p);
> +
> +	lockdep_assert_rq_held(src_rq);
> +
> +	if (!sched_proxy_exec())
> +		return true;
> +
> +	/* @p may be rq->curr under another task's proxy scheduling context. */
> +	if (task_on_cpu(src_rq, p))
> +		return false;
> +

[Severity: High]
Is it possible for the active scheduling context (the donor) to be migrated
here?

When a task blocks on a mutex and becomes a proxy donor, it is retained on
the runqueue (p->on_rq == 1) without being dequeued. put_prev_task_scx()
sees SCX_TASK_QUEUED and enqueues this blocked task onto a DSQ.

When another CPU attempts to consume from this DSQ, consume_remote_task()
invokes this new task_can_move_from_locked_rq(). Since the donor is
blocked, task_on_cpu(src_rq, p) evaluates to false.

Without a check for task_current_donor(src_rq, p), could this return true
and allow move_remote_task_to_local_dsq() to migrate the active donor,
corrupting the proxy execution PI chain?

> +	return !is_migration_disabled(p);
> +}

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