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

[Atul Kumar Pant]

On Tue, Aug 11, 2026 at 12:56:53PM -0700, John Stultz wrote:
> 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!
Yes the condition you described above is same that I was trying to
convey (affinity mask may not contain target_rq). We can probably
add a check to confirm whether the picked task 'p' is still blocked or
not.
Thank you for taking time and going through the comment.

Thanks,
Atul

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