Re: [PATCH 4/9] sched_ext: Handle blocked donor migration with proxy execution

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Plain data race on `rq->donor` in `task_current_donor()` during lockless evaluation triggers KCSAN warnings.
--

commit 6a880849b19162c80e0a10e017da8716e5ef3566
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 commit allows
normal sched_ext migration of blocked donors unless the donor is active
on its rq.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 4c6cd694c86db..e7cf88b2be7f6 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
[ ... ]
> @@ -2156,6 +2156,18 @@ 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 (task_is_blocked(p) && task_current_donor(task_rq(p), p))

[Severity: Medium]
Will this trigger KCSAN warnings due to a data race on rq->donor?

When consume_dispatch_q() calls task_can_run_on_remote_rq() with enforce=false
as an opportunistic lockless check, it only holds dsq->lock, not the runqueue
lock for task_rq(p).

This causes task_current_donor() to perform a plain read of rq->donor:

kernel/sched/sched.h:task_current_donor() {
    return rq->donor == p;
}

Since rq->donor can be concurrently modified by the runqueue's owner CPU,
the plain read violates the memory model. Even if it is logically safe
because the condition is re-evaluated later with the lock held, should
this be annotated with READ_ONCE() or data_race() to avoid KCSAN warnings?

> +		return false;
> +

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