Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock

[Mathieu Desnoyers]

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