Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock

From: Mathieu Desnoyers

Date: Thu Mar 12 2026 - 12:10:48 EST


On 2026-03-12 10:14, André Almeida wrote:


Em 12/03/2026 11:12, Florian Weimer escreveu:
* Mathieu Desnoyers:

On 2026-03-12 04:49, Florian Weimer wrote:
* Mathieu Desnoyers:

+ * 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);
The comment could perhaps say that pd->robust_head is the
thread-specific robust list that has been registered with
set_robust_list.

Good point. Considering that "robust_head" is the thread-specific
robust list registered with set_robust_list, I wonder if passing
&robust_head->list_op_pending is the right ABI choice there,
or if we should rather pass the robust_head pointer and offset it
within the vDSO.

I think set_robust_list has pointer and size arguments, so we should
pass those two at least.


The size argument for set_robust_list() has never been useful it seems, it just checks if (size == sizeof(*head)). I believe it was added in case the struct would ever be expanded, but that never happened and with set_robust_list2() in the horizon this is even less likely to ever happen.

I'd prefer not passing an extra parameter which would require the caller
to perform error validation unless it's really necessary.

The field we need to access (list_op_pending) is part of the original
structure, so it would be there even of this structure is extended in
the future.

Thanks,

Mathieu

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