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

John Stultz
2026-04-02T17:35:12Z

On Thu, Apr 2, 2026 at 7:43 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
>
> 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?
>

You hit the fallthrough line you quoted above, which puts you into:

force_return:
proxy_force_return(rq, rf, p);
return NULL;

Which will return the donor to a CPU it can run on.

Can you clarify more about the case you're worried about?

thanks
-john