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

[Mathieu Desnoyers]

On 2026-03-16 17:02, Thomas Gleixner wrote:
> On Mon, Mar 16 2026 at 15:19, Mathieu Desnoyers wrote:
> > On 2026-03-16 13:13, Thomas Gleixner wrote:
> > > +
> > > +static __always_inline void __user *x86_futex_robust_unlock_get_pop(struct pt_regs *regs)
> > > +{
> > > +	return (void __user *)regs->dx;
> >
> > When userspace is compat 32-bit, with a 64-bit kernel, are we sure that
> > the 32 upper bits are cleared ? If not can we rely on
> > compat_robust_list_clear_pending to ignore those top bits in
> > put_user(0U, pop) ?
>
> Which compat version are you talking about?
>
>    1) A 32-bit application which truly runs as compat
>
>    2) A 64-bit application which uses both variants and invokes the
>       64-bit VDSO from a 32-bit program segment
>
> #1 is inherently safe. The 32-bit application uses the compat 32-bit VDSO
>     which only accesses the lower half of the registers. So the mov $ptr,
>     %edx results in zero extending the 32-bit value. From the SDM:
>
>       "32-bit operands generate a 32-bit result, zero-extended to a
>        64-bit result in the destination general-purpose register."

Ah, very well, this is the important piece I was missing.

>     The exception/interrupt entry switches into 64-bit mode, but due to
>     the above the upper 32 bit are 0. So it's safe to just blindly use
>     regs->dx.

OK.

[...]

> #2 can really be assumed to be safe as there must be some magic
>     translation in the emulation code which handles the different calling
>     conventions.
[...]

Sounds good,

Thanks,

Mathieu

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