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

John Stultz
2026-04-02T17:43:15Z

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