Re: [patch 6/8] futex: Provide infrastructure to plug the non contended robust futex unlock race

[Thomas Gleixner <tglx@kernel.org>]

On Mon, Mar 16 2026 at 14:35, Mathieu Desnoyers wrote:

> On 2026-03-16 13:13, 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 #6 then the kernel robust
>
> "... before reaching #4 ...".
>
> [...]
>
>> 
>> As this is only relevant when the task was interrupted in user space, this
>> is tied to RSEQ and the generic entry code as RSEQ keeps track of user
>> space interrupts unconditionally even if the task does not have a RSEQ
>> region installed. That makes the decision very lightweight:
>> 
>>         if (current->rseq.user_irq && within(regs, unlock_ip_range))
>>         		futex_fixup_robust_unlock(regs);
>
> Nice trick to re-use the rseq infra, but where is the added dependency
> on CONFIG_RSEQ=y ?

Here:

 +config FUTEX_ROBUST_UNLOCK
 +       def_bool FUTEX && HAVE_GENERIC_VDSO && GENERIC_IRQ_ENTRY && RSEQ && HAVE_FUTEX_ROBUST_UNLOCK