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

[Peter Zijlstra]

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.