Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-03-12 16:19, Thomas Gleixner wrote:
> On Thu, Mar 12 2026 at 10:46, André Almeida wrote:
>> Em 11/03/2026 15:54, Mathieu Desnoyers escreveu:
>> 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.
> 
> That's true for non-robust futexes, but robust futexes have clearly
> defined semantics vs. the userspace value:
> 
>          0:	unlocked
>          != 0:	PID of the owner
> 
> So uval is useless as the unlock value can't be anything else than 0,
> no?

Yes, that was my original assumption, hence why I did not have a
"val" parameter (and internally used 0 within the vDSO). I can
go back to that behavior in a following version.

Just to confirm: for robust PI futexes, the value used for
the cmpxchg store would always be 0 as well, right ?
If that's the case, having an input "val" is useless there
too, and we just need a pointer to an expected/loaded value.

I'm also not convinced that adding a _u32 suffix to the
vDSO symbol is useful if the robust futexes already define
the futex value to be 32-bit wide.

Thanks,

Mathieu

> 
> Thanks,
> 
>          tglx


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