Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock

[Mathieu Desnoyers]

On 2026-03-12 09:46, André Almeida wrote:
> 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)

I agree on adding explicit "uval" and pointer to robust list head,
I'm not convinced that the rest is an improvement.

This would require the caller to deal with errors, making it
more complex than a simple replacement for atomic xchg/cmpxchg.

"flags" could be unsupported, so the handler would have to deal with
-EINVAL.

The "size" could be unsupported (e.g. 64-bit on a 32-bit arch), which
would also require the caller to deal with -EINVAL.

> First because we have FUTEX2_SIZE's, so uaddr could have different size 
> here.

Even in your proposal, "int uval" would be limited to 32-bit and would
not cover the 64-bit size case. Making this input parameter a void
pointer would remove type validation and adds complexity.

> 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().

But adding flags leaves additional error handling burden for the caller.
I'm not sure it's a win.

> 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.

Agreed on adding a u32 val parameter.

We can specialise the vdso for the size, e.g.:

extern u32 __vdso_robust_futex_unlock_u32(u32 *uaddr, u32 val, struct robust_list_head *robust_list_head);

and eventually add vdsos for u8, u16, u64.

Thoughts ?

Thanks,

Mathieu

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