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

[Mathieu Desnoyers]

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 ?

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com