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

[John Stultz]

On Thu, Apr 2, 2026 at 7:43 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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