Re: [PATCH 1/1] sched/core: Don't steal a proxy-exec donor

[K Prateek Nayak]

Hello Vasily,

On 5/4/2026 6:01 PM, Vasily Gorbik wrote:
> try_steal_cookie() avoids stealing src->core_pick and src->curr before
> moving a task with the same cookie via move_queued_task_locked().
> 
> With proxy-exec, src->donor is the current scheduling context and may
> differ from src->curr. Stealing it migrates a task that the source rq
> still treats as current. For CFS, src cfs_rq->curr is left pointing
> at the stolen entity and the next pick on src hits the WARN_ON_ONCE
> in put_prev_entity().
> 
> Commit 7de9d4f94638 ("sched: Start blocked_on chain processing in
> find_proxy_task()") tweaked the fair class logic so that the donor task
> isn't migrated away while running the proxy. Do it similarly for
> try_steal_cookie() and skip src->donor as well.
> 
> Fixes: 7de9d4f94638 ("sched: Start blocked_on chain processing in find_proxy_task()")
> Signed-off-by: Vasily Gorbik <gor@xxxxxxxxxxxxx>
> ---
>  kernel/sched/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b8871449d3c6..3cf5fb70814c 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6358,7 +6358,7 @@ static bool try_steal_cookie(int this, int that)
>  		return false;
>  
>  	do {
> -		if (p == src->core_pick || p == src->curr)
> +		if (p == src->core_pick || p == src->curr || p == src->donor)

Although this solves the issue of stealing the donor, I'm a bit
skeptical if proxy exec even works with core scheduling at all since
__schedule() can override the decision of core_pick and the CPU
may end up running a task with different core-cookie if it found
the core_pick to be blocked on a mutex :-(

>  			goto next;
>  
>  		if (!is_cpu_allowed(p, this))

-- 
Thanks and Regards,
Prateek