Re: [PATCH v26 10/10] sched: Handle blocked-waiter migration (and return migration)

[Peter Zijlstra <peterz@infradead.org>]

So with that other issue cured, I'm back to staring at this thing....

On Tue, Mar 24, 2026 at 07:13:25PM +0000, John Stultz wrote:
> +static bool proxy_deactivate(struct rq *rq, struct task_struct *donor)
>  {
>  	unsigned long state = READ_ONCE(donor->__state);
>  
> @@ -6598,17 +6610,140 @@ static bool __proxy_deactivate(struct rq *rq, struct task_struct *donor)
>  	return try_to_block_task(rq, donor, &state, true);
>  }
>  

> @@ -6741,7 +6900,17 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
>  	/* Handle actions we need to do outside of the guard() scope */
>  	switch (action) {
>  	case DEACTIVATE_DONOR:
> -		return proxy_deactivate(rq, donor);
> +		if (proxy_deactivate(rq, donor))
> +			return NULL;
> +		/* If deactivate fails, force return */
> +		p = donor;
> +		fallthrough;

I was going to reply to Prateek's email and was going over the whole
ttwu path because of that, and that got me looking at this.

What happens here if donor is migrated; the current CPU no longer valid
and we fail proxy_deactivate() because of a pending signal?