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

[Yao Kai]

On 7/21/2026 3:23 PM, Sebastian Andrzej Siewior wrote:
> 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.

Unless I am missing something, spin_lock() does not use the regular
rt_mutex pre/schedule/post sequence on PREEMPT_RT. Its contended path
uses schedule_rtlock():

  spin_lock()
    rt_spin_lock()
      _rt_spin_lock()
        rtlock_lock()
          lockdep_assert(!current->pi_blocked_on);
          rtlock_slowlock()
            rtlock_slowlock_locked()
              schedule_rtlock()

At this point current->pi_blocked_on has already been cleared ,so the
assertion in rtlock_lock() is also satisfied.

That said, I think it is also acceptable to place
rt_mutex_post_schedule() immediately after rt_mutex_wait_proxy_lock().

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

Yao