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

[John Stultz]

On Tue, May 26, 2026 at 4:39 PM John Stultz <jstultz@xxxxxxxxxx> wrote:
> On Tue, May 26, 2026 at 4:16 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > Per the discussion here:
> >
> >   https://lore.kernel.org/all/20260403112810.GG3738786@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> >
> > 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@xxxxxxxxxxxxx>
> > ---
> >  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@xxxxxxxxxx/

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@xxxxxxxxxx>

thanks
-john