Re: [RESEND][PATCH v31 8/9] sched: Add deactivated (sleeping) owner handling to find_proxy_task()

[John Stultz]

On Tue, Aug 11, 2026 at 12:09 PM Atul Kumar Pant
<atulpant.linux@xxxxxxxxx> wrote:
> On Fri, Aug 07, 2026 at 03:52:14AM +0000, John Stultz wrote:
> > +static void do_activate_blocked_waiter(struct rq *target_rq, struct task_struct *p, int en_flags)
> > +{
> > +     unsigned int state;
> > +     struct rq_flags rf;
> > +     int target_cpu = cpu_of(target_rq);
> > +
> > +     scoped_guard (raw_spinlock_irqsave, &p->pi_lock) {
> > +             state = READ_ONCE(p->__state);
> > +             /* Avoid racing with ttwu */
> > +             if (state == TASK_WAKING)
> > +                     return;
> > +
> > +             if (READ_ONCE(p->on_rq)) {
> > +                     /*
> > +                      * We raced with a non mutex handoff activation of p.
> > +                      * That activation will also take care of activating
> > +                      * all of the tasks after p in the blocked_head list,
> > +                      * so we're done here.
> > +                      */
> > +                     return;
> > +             }
> > +             if (task_on_cpu(task_rq(p), p)) {
> > +                     /*
> > +                      * Its possible this activation is very late, and
> > +                      * we already were woken up and are running on a
> > +                      * different cpu. If that task blocked, it could be
> > +                      * dequeued (so on_rq == 0), but still on_cpu.
> > +                      * Bail in this case, as we definitely don't want to
> > +                      * activate a task when its on_cpu elsewhere.
> > +                      */
> > +                     return;
> > +             }
>
>         Hi John,
>         one doubt, can It happen that this task 'p' has already finished running
>         in between the time when it was was picked from blocked list
>         (activate_blocked_waiters()) and this function? I mean, is it possible
>         for 'p' that task_is_blocked() is false?

So, I'm not totally sure I have in mind what you do, but yes. Most of
the conditions we are checking in the above are dealing with
blocked-waiter tasks being woken up in parallel with teh
activate_blocked_waiters() logic.

Are you suggesting that we should include an additional check on
is_blocked before we do the activation?

I guess I could see the concern if the task was woken in parallel and
ran and and then went to sleep (so its not on_rq or on_cpu). Normally
spuriously activating the task wouldn't have much impact (it would
wake, loop and go back to sleep), but I guess there is the risk here
that since we're activating it to be a donor on the waking lock
owner's rq here, the target_rq may not be in the donors affinity mask,
so that could be a problem.

So yeah, it seems an extra is_blocked check is probably warrented
here. Thanks for pointing that out!

If that wasn't what you had in mind, please do let me know!

thanks
-john