[PATCH v3 2/5] arm64: vdso: Implement __vdso_futex_robust_try_unlock()

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Fri May 29 10:47:28 PDT 2026


On 2026-05-29 12:33, André Almeida wrote:
> Based on the x86 implementation, implement the vDSO function for unlocking
> a robust futex correctly.
> 
> Commit xxxxxxxxxxxx ("x86/vdso: Implement __vdso_futex_robust_try_unlock()") has
> the full explanation about why this mechanism is needed.
> 
> The unlock assembly sequence for arm64 is:
> 
> 	__vdso_futex_robust_list64_try_unlock:
> 	retry:
> 		ldxr	w8, [x0] // Load the value from *futex
> 		cmp	w1, w8   // Compare with TID
> 		b.ne	__vdso_futex_list64_try_unlock_cs_end
> 		stlxr	w9, wzr, [x0] // Try to zero *futex

So it looks like stlxr can be successful, and the process is killed
right here. This is not within the start/end critical section, so the
fixup is missed ? Or am I missing something ?

> 		cbnz	w9, retry
> 	__vdso_futex_list64_try_unlock_cs_start:
> 		str	xzr, [x2] // After zeroing *futex, zero *op_pending
> 	__vdso_futex_list64_try_unlock_cs_end>:
> 
> The decision regarding if the pointer should be cleared or not lies on checking
> the condition flag zero:
> 
> 	return (regs->user_regs.pstate & PSR_Z_BIT) ?
> 		(void __user *) regs->user_regs.regs[2] : NULL;
> 
> If it's not zero, that means that the comparassion worked and the kernel should

comparison

> clear op_pending (if userspace didn't managed to) stored at x2.
Thanks,

Mathieu

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



More information about the linux-arm-kernel mailing list