[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