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

[Thomas Weißschuh]

On Tue, Mar 17, 2026 at 10:51:47AM +0100, Thomas Gleixner wrote:
> On Tue, Mar 17 2026 at 08:25, Thomas Weißschuh wrote:
> > On Mon, Mar 16, 2026 at 06:13:34PM +0100, Thomas Gleixner wrote:
> >> +/*
> >> + * Compat enabled kernels have to take the size bit into account to support the
> >> + * mixed size use case of gaming emulators. Contrary to the kernel robust unlock
> >> + * mechanism all of this does not test for the 32-bit modifier in 32-bit VDSOs
> >> + * and in compat disabled kernels. User space can keep the pieces.
> >> + */
> >> +#if defined(CONFIG_X86_64) && !defined(BUILD_VDSO32_64)
> >
> > #ifndef __x86_64__ ?
> 
> #ifdef :)

Indeed :-)

> Just had to double check and convince myself that __x86_64__ is set when
> building for the X86_X32 ABI. Seems to work.

Afaik this is mandated by the x32 ABI. Together with __ILP32__.
In any case it doesn't matter as the x32 vDSO is not actually built but
instead is a copy of the x86_64 one with its elf type patched around.

(...)

> >> --- a/arch/x86/entry/vdso/vdso64/vdsox32.lds.S
> >> +++ b/arch/x86/entry/vdso/vdso64/vdsox32.lds.S
> >> @@ -22,6 +22,12 @@ VERSION {
> >>  		__vdso_getcpu;
> >>  		__vdso_time;
> >>  		__vdso_clock_getres;
> >> +#ifdef CONFIG_FUTEX_ROBUST_UNLOCK
> >> +		__vdso_futex_robust_try_unlock;
> >
> >> +		__vdso_futex_robust_try_unlock_cs_start;
> >> +		__vdso_futex_robust_try_unlock_cs_success;
> >> +		__vdso_futex_robust_try_unlock_cs_end;
> >
> > These three symbols are not meant to be used from outside the vDSO
> > implementation, so they don't need to be exported by the linkerscripts.
> 
> You are right in principle and I had it differently in the first place
> until I realized that exposing them is useful for debugging and
> validation purposes.
> 
> As I pointed out in the cover letter you can use GDB to actually verify
> the fixup magic. That makes it obviously possible to write a user space
> selftest without requiring to decode the internals of the VDSO.
> 
> Due to my pretty limited userspace DSO knowledge that was the best I
> came up with. If you have a better idea, please let me know.

I would have expected GDB to be able to use the separate vDSO debugging
symbols to find these symbols. So far I was not able to make it work,
but I blame my limited GDB knowledge.

Or move the symbols into a dedicated version to make clear that this is
not a stable interface.


Thomas