Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock

[André Almeida]

Hi Mathieu,

Thanks for your patch!

Em 11/03/2026 15:54, Mathieu Desnoyers escreveu:
> This vDSO unlocks the robust futex by exchanging the content of
> *uaddr with 0 with a store-release semantic. If the futex has
> waiters, it sets bit 1 of *op_pending_addr, else it clears
> *op_pending_addr. Those operations are within a code region
> known by the kernel, making them safe with respect to asynchronous
> program termination either from thread context or from a nested
> signal handler.
>
> Expected use of this vDSO:
>
> if ((__vdso_robust_futex_unlock((u32 *) &mutex->__data.__lock, &pd->robust_head.list_op_pending)
>      & FUTEX_WAITERS) != 0)
>          futex_wake((u32 *) &mutex->__data.__lock, 1, private);
> WRITE_ONCE(pd->robust_head.list_op_pending, 0);

[...]

> +
> +u32 __vdso_robust_futex_unlock(u32 *uaddr, uintptr_t *op_pending_addr)
> +{

The interface that I would propose here would be a bit more "generic" or 
"flexible":

__vdso_robust_futex_unlock(void *uaddr, int uval, struct 
robust_list_head *head, unsigned int flags)

First because we have FUTEX2_SIZE's, so uaddr could have different size 
here. And we need `flags` to determine the size. Also `flags` is a great 
way to expand this funciton in the future without the need to create 
__vdso_robust_futex_unlock2().

I would also have `uval` instead of `val = 0`, because even though the 
most common semanthics for futex is that (LOCK_FREE == 0), futex has no 
predetermined semanthics of what each value means, and the userspace is 
free to choose what value they want to choose for a free lock.

And as you already highlighted in the other thread, I agree that `struct 
robust_list_head` instead of just the op_pending address is more 
flexible as well.

Thanks!