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

[John Stultz]

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/

Since without that, we can get into a situation where we have
blocked_on set when a task __state is TASK_RUNNING.  The segment
you're dropping would catch and clear that out, but really we should
avoid getting into that situation in the mutex lock code.

thanks
-john