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

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, Aug 27 2026 at 10:37, Sebastian Andrzej Siewior wrote:
> 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/

That makes sense.