Re: [patch V5 11/16] futex: Provide infrastructure to plug the non contended robust futex unlock race

[Thomas Gleixner <tglx@kernel.org>]

On Wed, Jun 03 2026 at 11:23, Peter Zijlstra wrote:

> On Tue, Jun 02, 2026 at 11:10:04AM +0200, Thomas Gleixner wrote:
>> When the FUTEX_ROBUST_UNLOCK mechanism is used for unlocking (PI-)futexes,
>> then the unlock sequence in user space looks like this:
>> 
>>   1)	robust_list_set_op_pending(mutex);
>>   2)	robust_list_remove(mutex);
>> 	
>>   	lval = gettid();
>>   3)	if (atomic_try_cmpxchg(&mutex->lock, lval, 0))
>>   4)		robust_list_clear_op_pending();
>>   	else
>>   5)		sys_futex(OP | FUTEX_ROBUST_UNLOCK, ....);
>> 
>> That still leaves a minimal race window between #3 and #4 where the mutex
>> could be acquired by some other task, which observes that it is the last
>> user and:
>> 
>>   1) unmaps the mutex memory
>>   2) maps a different file, which ends up covering the same address
>> 
>> When then the original task exits before reaching #5 then the kernel robust
>> list handling observes the pending op entry and tries to fix up user space.
>
> This #5 reference, should be #4, yeah? Same bit of Changelog is
> replicated in a later patch and has the same issue.

Yes.