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

[Yao Kai <yaokai34@huawei.com>]

On 8/4/2026 8:21 PM, Peter Zijlstra wrote:
> On Wed, Jul 22, 2026 at 04:51:39PM +0800, Yao Kai wrote:
>> A waiter requeued onto a PI futex can reach rt_mutex_wait_proxy_lock()
>> without rtmutex schedule preparation:
>>
>>    WARNING: CPU: 0 PID: 293 at kernel/sched/core.c:7606
>>    RIP: rt_mutex_schedule+0x43/0x50
>>    Call Trace:
>>     rt_mutex_slowlock_block.constprop.0+0x5b/0x320
>>     rt_mutex_wait_proxy_lock+0x3e/0x80
>>     futex_wait_requeue_pi+0x3ba/0x590
>>     do_futex+0x171/0x1f0
>>
>> rt_mutex_schedule() requires current->sched_rt_mutex to be set. Normally,
>> rt_mutex_pre_schedule() sets it before an rtmutex waiter can schedule. With
>> requeue PI, another task can enqueue the waiter after its futex_q becomes
>> visible:
>>
>>          waiter                          requeue task
>>          ------                          ------------
>> futex_wait_requeue_pi()
>>    futex_wait_setup()
>>      futex_queue(&q)
>>                                          futex_requeue()
>>                                            rt_mutex_start_proxy_lock()
>>                                              enqueue rt_waiter
>>                                              install pi_blocked_on
>>                                            requeue_futex()
>>                                              plist_del(&q->list)
>>    futex_do_wait()
>>      plist_node_empty(&q->list)
>>      skip schedule()
>>                                              plist_add(&q->list)
>>                                            futex_requeue_pi_complete()
>>                                              IN_PROGRESS -> DONE
>>    futex_requeue_pi_wakeup_sync() // DONE
>>    rt_mutex_wait_proxy_lock()
>>      rt_mutex_schedule()
>>
>> futex_do_wait() mistakes the temporary removal for a wakeup and skips
>> schedule(). The proxy waiter can nevertheless remain blocked on the target
>> rtmutex and subsequently enter rt_mutex_schedule() with
>> current->sched_rt_mutex clear.
>>
>> Call rt_mutex_pre_schedule() and rt_mutex_post_schedule() directly around
>> rt_mutex_wait_proxy_lock() so this second blocking point has the required
>> scheduler preparation.
>>
>> Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers")
>> Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Yao Kai <yaokai34@huawei.com>
>> ---
>>   kernel/futex/requeue.c | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c
>> index 79823ad13683..f7889fb2fce4 100644
>> --- a/kernel/futex/requeue.c
>> +++ b/kernel/futex/requeue.c
>> @@ -1,6 +1,7 @@
>>   // SPDX-License-Identifier: GPL-2.0-or-later
>>   
>>   #include <linux/plist.h>
>> +#include <linux/sched/rt.h>
>>   #include <linux/sched/signal.h>
>>   
>>   #include "futex.h"
>> @@ -865,7 +866,14 @@ 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;
>> +		/*
>> +		 * Requeue temporarily removes q from the hash bucket, so
>> +		 * futex_do_wait() may skip schedule() even though the proxy
>> +		 * waiter still has to block on the rtmutex.
>> +		 */
>> +		rt_mutex_pre_schedule();
>>   		ret = rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter);
>> +		rt_mutex_post_schedule();
> 
> As per always, I'm totally confused about everything. I mean, futexes
> suck, but requeue sucks worse.
> 
> So the purpose of rt_mutex_pre_schedule() was to avoid the double waiter
> enqueue for rt_mutex on RT, where sched_submit_work() will hit a
> spinlock-nee-rtlock.
> 
> So rt_mutex_pre_schedule() must happen before the rt_mutex is added as a
> waiter. However, AFAICT we're already a waiter at the above spot, no? So
> this cannot be right.
> 
> The changelogs doesn't at all explain why this is correct. Please help?

You are right that rt_mutex_pre_schedule() is normally required before the
rtmutex waiter is enqueued.

The v2 placement relies on a property of this particular call path that I
failed to explain in the changelog: futex_wait_requeue_pi() is reachable
only via the FUTEX_WAIT_REQUEUE_PI syscall from userspace. Therefore,
'current' cannot be a workqueue/io-wq worker, nor can it carry a live
block plug across the syscall boundary.

Consequently, sched_submit_work() inside rt_mutex_pre_schedule() has no
pending plugged I/O or worker notifications to process here, so it cannot
recurse into an rtlock after the proxy waiter has been installed. In this
specific path, calling rt_mutex_pre_schedule() here effectively only sets
current->sched_rt_mutex before rt_mutex_wait_proxy_lock() calls
rt_mutex_schedule(), without executing any blocking submit_work after enqueue.

This was the rationale for adopting Sebastian's simpler suggestion from the
v1 discussion, but this essential invariant was omitted from the v2
changelog and code comments.

Thanks,
Yao Kai