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

[Yao Kai <yaokai34@huawei.com>]

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