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

[Sebastian Andrzej Siewior]

On 2026-07-17 16:49:21 [+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 and submits pending work before the waiter
> is enqueued. 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 waiter consequently enters rt_mutex_schedule() with
> current->sched_rt_mutex clear. Its block plug remains unflushed, and
> workqueue or io-wq users are not notified that the worker is going to
> sleep.

This has nothing to do with, does it? It is just usually the lock is
acquired and it is not blocked on. Do you have testcase for this or is
this just audit?

> rt_mutex_pre_schedule() cannot be used directly. Calling it before q is
> published would set current->sched_rt_mutex while futex_do_wait() can still
> call regular schedule(). Calling it after DONE would flush the block plug
> after current->pi_blocked_on is installed, which can recurse into rtmutex
> waiter setup.
> 
> Split the preparation instead. Flush the plug before futex_wait_setup()
> publishes q. After futex_requeue_pi_wakeup_sync() returns DONE, enter the
> rtmutex scheduling state and notify workqueue and io-wq users without
> flushing the plug again. Split sched_submit_work() to support this ordering
> and leave the scheduling state after the waiter has acquired the lock or
> has been removed.
> 
> Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Yao Kai <yaokai34@xxxxxxxxxx>

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.