Re: [PATCH 2/2] locking: mutex: Fix proxy-exec potentially deactivating tasks marked TASK_RUNNING

[John Stultz]

On Tue, Apr 28, 2026 at 1:16 AM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> On 4/28/2026 12:08 AM, John Stultz wrote:
> I think this too requires a:
>
> Fixes: be41bde4c3a8 ("sched: Add an initial sketch of the find_proxy_task() function")
>
> With that, feel free to include:
>
> Reviewed-by: K Prateek Nayak <kprateek.nayak@xxxxxxx>

Thanks so much for looking this over!

> > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> > index 09534628dc01a..a93d4c6bee1a3 100644
> > --- a/kernel/locking/mutex.c
> > +++ b/kernel/locking/mutex.c
> > @@ -763,6 +763,7 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
> >                       raw_spin_lock_irqsave(&lock->wait_lock, flags);
> >                       raw_spin_lock(&current->blocked_lock);
> >                       __set_task_blocked_on(current, lock);
> > +                     set_current_state(state);
> >
> >                       if (opt_acquired)
> >                               break;
>
> nit.
>
> As a micro-optimization, you can probably move the
> __set_task_blocked_on() and set_current_state() after this break.

So my main reason for setting it before the break makes it symmetric
with the clearing that happens just outside the loop. Feels a little
cleaner to me for it to all match.

thanks
-john