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

[John Stultz]

On Thu, Apr 2, 2026 at 8:08 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Thu, Apr 02, 2026 at 04:43:02PM +0200, Peter Zijlstra 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?
>
> Something like so?
>
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6515,7 +6540,6 @@ static bool try_to_block_task(struct rq
>                               unsigned long *task_state_p, bool should_block)
>  {
>         unsigned long task_state = *task_state_p;
> -       int flags = DEQUEUE_NOCLOCK;
>
>         if (signal_pending_state(task_state, p)) {
>                 WRITE_ONCE(p->__state, TASK_RUNNING);
...
> @@ -6599,7 +6604,8 @@ static bool proxy_deactivate(struct rq *
>          * need to be changed from next *before* we deactivate.
>          */
>         proxy_resched_idle(rq);
> -       return try_to_block_task(rq, donor, &state, true);
> +       block_task(rq, donor, state);
> +       return true;
>  }
>
>  static inline void proxy_release_rq_lock(struct rq *rq, struct rq_flags *rf)

So, it seems like this would just causes us to ignore the pending
signal(and just do the deactivation)? I'm not sure why that's
desired...

thanks
-john