Re: [PATCH 1/6] sched/proxy: Remove superfluous clear_task_blocked_in()

[Peter Zijlstra <peterz@infradead.org>]

On Tue, May 26, 2026 at 04:54:01PM -0700, John Stultz wrote:
> On Tue, May 26, 2026 at 4:39 PM John Stultz <jstultz@google.com> wrote:
> > On Tue, May 26, 2026 at 4:16 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > Per the discussion here:
> > >
> > >   https://lore.kernel.org/all/20260403112810.GG3738786@noisy.programming.kicks-ass.net/
> > >
> > > The reason for this condition is that the signal condition in
> > > try_to_block_task() would set_task_blocked_in_waking(). However, it no longer
> > > does that, in fact, that path does clear_task_blocked_on(), rendering the
> > > clause under discussion moot.
> > >
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > ---
> > >  kernel/sched/core.c |    3 ---
> > >  1 file changed, 3 deletions(-)
> > >
> > > --- a/kernel/sched/core.c
> > > +++ b/kernel/sched/core.c
> > > @@ -7132,9 +7132,6 @@ static void __sched notrace __schedule(i
> > >         if (sched_proxy_exec()) {
> > >                 struct task_struct *prev_donor = rq->donor;
> > >
> > > -               if (!prev_state && prev->blocked_on)
> > > -                       clear_task_blocked_on(prev, NULL);
> > > -
> > >                 rq_set_donor(rq, next);
> > >                 next->blocked_donor = NULL;
> > >                 if (unlikely(next->is_blocked && next->blocked_on)) {
> >
> > Oh good! I had a note to try to re-confirm if that chunk was really
> > needed, as it did feel a bit like it was patching up a problem after
> > the fact.
> >
> > That said, running this on top of your sched/proxy branch tripped over
> > warnings with the ww_mutex selftest, so it looks like there's
> > something else missing before this can land.
> >
> > Digging in, it looks like we still need the fix I had here:
> >   https://lore.kernel.org/lkml/20260430215103.2978955-3-jstultz@google.com/

Right, that patch looks reasonable, pulled that in.

> I'll be doing some stress testing with the rest of set later, but so
> far with the extra fix I pointed to this is looking ok
> Acked-by: John Stultz <jstultz@google.com>

Thanks!