Re: [PATCH v3 1/2] futex: Add missing rt_mutex_.*_schedule() around rt_mutex_wait_proxy_lock()

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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@huawei.com/

which is what I had in mind.

Sebastian