Re: [patch 8/8] x86/vdso: Implement __vdso_futex_robust_try_unlock()

[Thomas Gleixner]

On Tue, Mar 17 2026 at 09:28, Florian Weimer wrote:
> * Thomas Gleixner:
>
>> Arguably this could be avoided by providing separate functions and making
>> the IP range for the quick check in the exit to user path cover the whole
>> text section which contains the two functions. But that's not a win at all
>> because:
>>
>>    1) User space needs to handle the two variants instead of just
>>       relying on a bit which can be saved in the mutex at
>>       initialization time.
>
> I'm pretty sure that on the user-space side, we wouldn't have
> cross-word-size operations (e.g., 64-bit code working on both 64-bit and
> 32-bit robust mutexes).  Certainly not within libcs.  The other point
> about complexity is of course still valid.

Right, I know that no libc implementation supports such an insanity, but
the kernel unfortunately allows to do so and it's used in the wild :(

So we have to deal with it somehow and the size modifier was the most
straight forward solution I could come up with. I'm all ears if someone
has a better idea.

That said, do you see any issue from libc size versus extending the
WAKE/UNLOCK_PI functionality with that UNLOCK_ROBUST functionality?

I did some basic performance tests in the meanwhile with an open coded
mutex implementation. I can't observe any significant difference between
doing the unlock in user space or letting the kernel do it, but that
needs of course more scrunity.

Thanks,

        tglx