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

[Yao Kai <yaokai34@huawei.com>]

On 7/20/2026 10:58 PM, Sebastian Andrzej Siewior wrote:
> On 2026-07-20 10:40:03 [+0800], Yao Kai wrote:
>> I have a test but it only triggers the warning. The concern about calling
>> rt_mutex_pre_schedule() after the proxy waiter has been enqueued came from
>> audit. A generic PREEMPT_RT path could be:
>>
>>    rt_mutex_pre_schedule()
>>      sched_submit_work()
>>        blk_flush_plug()
>>          __blk_flush_plug()
>>            flush_plug_callbacks()
>>              drbd_unplug()
>>                spin_lock_irq()
>>                  rtlock_slowlock()
>>                    task_blocks_on_rt_mutex()
>>                      current->pi_blocked_on = waiter
>>
>> However, I could not find a path for FUTEX_WAIT_REQUEUE_PI to enter with a
>> live current->plug or worker flags, so this recursion is not reachable from
>> this syscall.
> 
> So the suggestion is okay then?
> …
> 

Yes.

>>> what about the following? This might compile but lacks all kind of testing.
>>>
>>> diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c
>>> index 79823ad136830..42a04e6e774c4 100644
>>> --- a/kernel/futex/requeue.c
>>> +++ b/kernel/futex/requeue.c
>>> @@ -865,7 +865,9 @@ 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);
>>> +		rt_mutex_post_schedule();
>>>    		/*
>>>    		 * See futex_unlock_pi()'s cleanup: comment.
>>
>> This also fixes the warning in my test. I would keep rt_mutex_post_schedule()
>> after the proxy waiter cleanup, as futex_lock_pi() does:
> 
> But why?
> 

Just to be consistent with the code in futex_lock_pi():

         ret = rt_mutex_wait_proxy_lock(&q.pi_state->pi_mutex, to, &rt_waiter);
                                                                                     
    cleanup:
         /*
          * If we failed to acquire the lock (deadlock/signal/timeout), we must
          * unwind the above, however we canont lock hb->lock because
          * rt_mutex already has a waiter enqueued and hb->lock can itself try
          * and enqueue an rt_waiter through rtlock.
          *
          * Doing the cleanup without holding hb->lock can cause inconsistent
          * state between hb and pi_state, but only in the direction of not
          * seeing a waiter that is leaving.
          *
          * See futex_unlock_pi(), it deals with this inconsistency.
          *
          * There be dragons here, since we must deal with the inconsistency on
          * the way out (here), it is impossible to detect/warn about the race
          * the other way around (missing an incoming waiter).
          *
          * What could possibly go wrong...
          */
         if (ret && !rt_mutex_cleanup_proxy_lock(&q.pi_state->pi_mutex, &rt_waiter))
           ret = 0;
                                                                                     
         /*
          * Now that the rt_waiter has been dequeued, it is safe to use
          * spinlock/rtlock (which might enqueue its own rt_waiter) and fix up
          * the
          */
         futex_q_lockptr_lock(&q);
         /*
          * Waiter is unqueued.
          */
         rt_mutex_post_schedule();


>> 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.

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