Re: [patch V3 00/14] futex: Address the robust futex unlock race for real

[Thomas Gleixner <tglx@kernel.org>]

On Mon, Mar 30 2026 at 14:45, Mark Rutland wrote:
> On Mon, Mar 30, 2026 at 02:01:58PM +0200, Thomas Gleixner wrote:
>> User space can't solve this problem without help from the kernel. This
>> series provides the kernel side infrastructure to help it along:
[ 6 more citation lines. Click/Enter to show. ]
>> 
>>   1) Combined unlock, pointer clearing, wake-up for the contended case
>> 
>>   2) VDSO based unlock and pointer clearing helpers with a fix-up function
>>      in the kernel when user space was interrupted within the critical
>>      section.
>
> I see the vdso bits in this series are specific to x86. Do other
> architectures need something here?

Yes.

> I might be missing some context; I'm not sure whether that's not
> necessary or just not implemented by this series, and so I'm not sure
> whether arm64 folk and other need to go dig into this.

The VDSO functions __vdso_futex_robust_list64_try_unlock() and
__vdso_futex_robust_list32_try_unlock() are architecture specific.

The scheme in x86 ASM is:

	mov		%esi,%eax	// Load TID into EAX
	xor		%ecx,%ecx	// Set ECX to 0
	lock cmpxchg	%ecx,(%rdi)	// Try the TID -> 0 transition
  .Lstart:
	jnz    		.Lend
	movq		%rcx,(%rdx)	// Clear list_op_pending
  .Lend:
	ret

.Lstart is the start of the critical section, .Lend the end. These two
addresses need to be retrieved from the VDSO when the VDSO is mapped to
user space and stored in mm::futex:unlock::cs_ranges[]. See patch 11/14.

If the cmpxchg was successful, then the pending pointer has to be
cleared when user space was interrupted before reaching .Lend.

So .Lstart has to be immediately after the instruction which did the try
compare exchange and the architecture needs to have their ASM variant
and the helper function which tells the generic code whether the pointer
has to be cleared or not. On x86 that is:

	return regs->flags & X86_EFLAGS_ZF ? (void __user *)regs->dx : NULL;

as the result of CMPXCHG is in the Zero Flag and the pointer is in
[ER]DX. The former is defined by the ISA, the latter is enforced by the
ASM constraints and has to be kept in sync between the VDSO ASM and the
evaluation helper.

Do you see a problem with that on AARGH64?

Thanks,

	tglx