Re: [PATCH v3 1/2] futex: Add missing rt_mutex_.*_schedule() around rt_mutex_wait_proxy_lock()
From: Sebastian Andrzej Siewior
Date: Thu Aug 27 2026 - 04:37:44 EST
On 2026-08-26 20:06:11 [+0200], Thomas Gleixner wrote:
> On Mon, Aug 24 2026 at 15:23, Peter Zijlstra wrote:
> > On Mon, Aug 24, 2026 at 02:55:42PM +0200, Sebastian Andrzej Siewior wrote:
> >> #include "futex.h"
> >> @@ -865,7 +866,10 @@ 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;
> >> +
> >
> > /*
> > * Since current is doing the requeue, it cannot also be
> > * a waiter on the same futex.
> > */
>
> Current is not the task doing the requeue. Current is the requeued waiter which is
> blocked on the rtmutex.
>
> Though the change log is confusing at best. The whole requeue explanation
> is not really helpful IMO.
>
> The point is that _all_ invocations of rt_mutex_schedule() must be
> preceeded by a call to rt_mutex_pre_schedule() and followed by a call to
> rt_mutex_post_schedule().
>
> So this code simply failed to do that, which triggers the
> lockdep_assert() in rt_mutex_schedule().
>
> And it's obvious from the surrounding comments how this task got there, no?
I would suggest to strip it all from the futex part, not do the flush
and just please the assert so it keeps quiet. I did some explaining in
the v2 and then Yao suggested
https://lore.kernel.org/all/5df8a43e-11bb-4881-877d-40034c414984@xxxxxxxxxx/
which is what I had in mind.
Sebastian