Re: [PATCH 1/2] futex/requeue: Fix rtmutex schedule preparation for requeue PI

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-07-21 09:51:47 [+0800], Yao Kai wrote:
> > > diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c
> > > index 79823ad13683..41ffc795d12c 100644
> > > --- a/kernel/futex/requeue.c
> > > +++ b/kernel/futex/requeue.c
> > > @@ -865,6 +865,7 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
> > >          case Q_REQUEUE_PI_DONE:
> > >                  /* Requeue completed. Current is 'pi_blocked_on' the rtmutex */
> > >                  pi_mutex = &q.pi_state->pi_mutex;
> > > +               rt_mutex_pre_schedule();
> > >                  ret = rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter);
> > >                  /*
> > > @@ -875,6 +876,7 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
> > >                  futex_q_lockptr_lock(&q);
> > >                  debug_rt_mutex_free_waiter(&rt_waiter);
> > > +               rt_mutex_post_schedule();
> > 
> > But there is futex_q_lockptr_lock() from what I see in the context. This
> > one should trigger the warning if it is done as you suggest.
> > 
> 
> I don't think it would trigger the warning. At this point rt_mutex_wait_proxy_lock()
> or rt_mutex_cleanup_proxy_lock() has cleared current->pi_blocked_on.

No, they don't. There is still this lockdep_assert() on
current->sched_rt_mutex which ensures that you must always do
rt_mutex_pre_schedule(), rt_mutex_schedule(), rt_mutex_post_schedule()
in that order. And spin_lock() will do all three of the mutex is
contended. Therefore you can leave rt_mutex_pre_schedule() across
another possible rtmutex locking.

> > >                  /*
> > >                   * Fixup the pi_state owner and possibly acquire the lock if we
> > >                   * haven't already.
> > > 
> > > Thanks,
> > > Yao

Sebastian