Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock

[Florian Weimer]

* Mathieu Desnoyers:

> On 2026-03-12 15:10, Thomas Gleixner wrote:
>> On Thu, Mar 12 2026 at 10:04, Mathieu Desnoyers wrote:
>>> On 2026-03-12 09:46, André Almeida wrote:
>>>> 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.
>> What's the problem with that? pthread_mutex_unlock() has a return
>> value
>> too.
>
> My aim is to use this vDSO as a replacement for atomic xchg and atomic
> cmpxchg within library code. I am trying to make the transition as
> straightforward as possible considering that this is a design bug
> fix.
>
> If adding error handling at that precise point of the libc robust mutex
> unlock code is straightforward, I don't mind internally checking flags
> and returning -EINVAL, but I'd want to hear about preference from the
> libc people on this topic beforehand.

As a deallocation operation, unlock must not fail.  We would therefore
ignore the error return value (because EINVAL can only happen for
invalid arguments), or we'd terminate the process on failure.

Thanks,
Florian