[PATCH RFC v2 0/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()

[PATCH RFC v2 0/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()

[André Almeida]

Hi folks,

This is my take on implementing the new vDSO for unlocking a robust futex in
arm64. If you don't know what's that, Thomas wrote a good summary,
including the motivation for this work and the x86 implementation:

   https://lore.kernel.org/lkml/878qb89g7b.ffs@tglx/

There are some loose ends in my patchset so I'm sending as a RFC to ask
some questions:

 - If the process is interrupted between the labels, we need to check the
 conditional flags and clear the op_pending address from the register. Using
 objdump I see that op_pending addr is being stored at x2, but I suspect that
 this isn't stable, so I need to figure out how to make sure that the address
 will always be stored in the same register.
 - So far I have implemented only the LL/SC version to make review easier, but I
 can do the LSE version as well.

This patchset works fine with the tests proposed at
https://lore.kernel.org/lkml/20260330120118.012924430@kernel.org/

Changes from v1:
 - s/CONFIG_COMPAT/CONFIG_COMPAT_VDSO (Thomas Weißschuh)
 - Fixed linker not finding the symbols (Thomas Weißschuh)
v1: https://patch.msgid.link/20260417-tonyk-robust_arm-v1-0-03aa64e2ff1a@igalia.com

---
André Almeida (2):
      arm64: vdso: Prepare for robust futex unlock support
      arm64: vdso: Implement __vdso_futex_robust_try_unlock()

 arch/arm64/Kconfig                                 |  1 +
 arch/arm64/include/asm/futex_robust.h              | 35 +++++++++++++
 arch/arm64/kernel/vdso.c                           | 30 +++++++++++
 arch/arm64/kernel/vdso/Makefile                    |  9 +++-
 arch/arm64/kernel/vdso/vdso.lds.S                  | 11 ++++
 .../kernel/vdso/vfutex_robust_list_try_unlock.c    | 59 ++++++++++++++++++++++
 6 files changed, 144 insertions(+), 1 deletion(-)
---
base-commit: 0e8896e9899b607bb168c1cce340596b8c2e3e2b
change-id: 20260416-tonyk-robust_arm-54ff77d2c4e4

Best regards,
--  
André Almeida <andrealmeid@igalia.com>

[PATCH RFC v2 1/2] arm64: vdso: Prepare for robust futex unlock support

[André Almeida]

There will be a VDSO function to unlock non-contended robust futexes in
user space. The unlock sequence is racy vs. clearing the list_pending_op
pointer in the task's robust list head. To plug this race the kernel needs
to know the critical section window so it can clear the pointer when the
task is interrupted within that race window. The window is determined by
labels in the inline assembly.

Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
Changes from v1:
 - Fixed linker not finding VDSO symbols
---
 arch/arm64/kernel/vdso.c          | 30 ++++++++++++++++++++++++++++++
 arch/arm64/kernel/vdso/vdso.lds.S |  7 +++++++
 2 files changed, 37 insertions(+)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 592dd8668de4..f9c520a1c942 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -11,6 +11,7 @@
 #include <linux/clocksource.h>
 #include <linux/elf.h>
 #include <linux/err.h>
+#include <linux/futex.h>
 #include <linux/errno.h>
 #include <linux/gfp.h>
 #include <linux/kernel.h>
@@ -57,6 +58,33 @@ static struct vdso_abi_info vdso_info[] __ro_after_init = {
 #endif /* CONFIG_COMPAT_VDSO */
 };
 
+#ifdef CONFIG_FUTEX_ROBUST_UNLOCK
+static void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm)
+{
+	unsigned long vdso = (unsigned long) mm->context.vdso;
+	struct futex_mm_data *fd = &mm->futex;
+	uintptr_t success, end;
+
+	if (abi == VDSO_ABI_AA64) {
+		success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_success);
+		end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_end);
+
+		futex_set_vdso_cs_range(fd, 0, vdso, success, end, false);
+	}
+
+#ifdef CONFIG_COMPAT_VDSO
+	if (abi == VDSO_ABI_AA32) {
+		success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_success);
+		end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_end);
+
+		futex_set_vdso_cs_range(fd, 1, vdso, success, end, true);
+	}
+#endif
+}
+#else
+static inline void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm) { }
+#endif /* CONFIG_FUTEX_ROBUST_UNLOCK */
+
 static int vdso_mremap(const struct vm_special_mapping *sm,
 		struct vm_area_struct *new_vma)
 {
@@ -134,6 +162,8 @@ static int __setup_additional_pages(enum vdso_abi abi,
 	if (IS_ERR(ret))
 		goto up_fail;
 
+	vdso_futex_robust_unlock_update_ips(abi, mm);
+
 	return 0;
 
 up_fail:
diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
index 52314be29191..c532dae6ac8e 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -112,3 +112,10 @@ VERSION
  * Make the sigreturn code visible to the kernel.
  */
 VDSO_sigtramp		= __kernel_rt_sigreturn;
+
+VDSO_futex_list64_try_unlock_cs_success = __futex_list64_try_unlock_cs_success;
+VDSO_futex_list64_try_unlock_cs_end = __futex_list64_try_unlock_cs_end;
+#ifdef CONFIG_COMPAT_VDSO
+VDSO_futex_list32_try_unlock_cs_success = __futex_list32_try_unlock_cs_success;
+VDSO_futex_list32_try_unlock_cs_end = __futex_list32_try_unlock_cs_end;
+#endif

-- 
2.53.0

Re: [PATCH RFC v2 1/2] arm64: vdso: Prepare for robust futex unlock support

[Thomas Weißschuh]

Hi André,

Some more comments, after doing an actual proper review.

On 2026-04-24 15:56:00-0300, André Almeida wrote:
> There will be a VDSO function to unlock non-contended robust futexes in
> user space. The unlock sequence is racy vs. clearing the list_pending_op
> pointer in the task's robust list head. To plug this race the kernel needs
> to know the critical section window so it can clear the pointer when the
> task is interrupted within that race window. The window is determined by
> labels in the inline assembly.
> 
> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
> Changes from v1:
>  - Fixed linker not finding VDSO symbols
> ---
>  arch/arm64/kernel/vdso.c          | 30 ++++++++++++++++++++++++++++++
>  arch/arm64/kernel/vdso/vdso.lds.S |  7 +++++++
>  2 files changed, 37 insertions(+)

What is the reason for splitting the series into two patches?
To me it looks like it should be one patch.

> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> index 592dd8668de4..f9c520a1c942 100644
> --- a/arch/arm64/kernel/vdso.c
> +++ b/arch/arm64/kernel/vdso.c
> @@ -11,6 +11,7 @@
>  #include <linux/clocksource.h>
>  #include <linux/elf.h>
>  #include <linux/err.h>
> +#include <linux/futex.h>
>  #include <linux/errno.h>
>  #include <linux/gfp.h>
>  #include <linux/kernel.h>
> @@ -57,6 +58,33 @@ static struct vdso_abi_info vdso_info[] __ro_after_init = {
>  #endif /* CONFIG_COMPAT_VDSO */
>  };
>  
> +#ifdef CONFIG_FUTEX_ROBUST_UNLOCK
> +static void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm)
> +{
> +	unsigned long vdso = (unsigned long) mm->context.vdso;
> +	struct futex_mm_data *fd = &mm->futex;
> +	uintptr_t success, end;
> +
> +	if (abi == VDSO_ABI_AA64) {
> +		success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_success);
> +		end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_end);
> +
> +		futex_set_vdso_cs_range(fd, 0, vdso, success, end, false);

Both VDSO_SYMBOL() and futex_set_vdso_cs_range() add the vdso base
address to the symbol offsets. The value stored in .start_ip will be
wrong. The fact that futex_set_vdso_cs_range() does the addition looks
like an artifact of it being written for x86 first. IMO its interface
should be changed not to do the addition internally.

> +	}
> +
> +#ifdef CONFIG_COMPAT_VDSO
> +	if (abi == VDSO_ABI_AA32) {
> +		success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_success);
> +		end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_end);
> +
> +		futex_set_vdso_cs_range(fd, 1, vdso, success, end, true);
> +	}
> +#endif
> +}
> +#else
> +static inline void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm) { }
> +#endif /* CONFIG_FUTEX_ROBUST_UNLOCK */
> +
>  static int vdso_mremap(const struct vm_special_mapping *sm,
>  		struct vm_area_struct *new_vma)
>  {

(...)

Re: [PATCH RFC v2 1/2] arm64: vdso: Prepare for robust futex unlock support

[André Almeida]

Em 26/04/2026 15:07, Thomas Weißschuh escreveu:
> Hi André,
> 
> Some more comments, after doing an actual proper review.
> 
> On 2026-04-24 15:56:00-0300, André Almeida wrote:
>> There will be a VDSO function to unlock non-contended robust futexes in
>> user space. The unlock sequence is racy vs. clearing the list_pending_op
>> pointer in the task's robust list head. To plug this race the kernel needs
>> to know the critical section window so it can clear the pointer when the
>> task is interrupted within that race window. The window is determined by
>> labels in the inline assembly.
>>
>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
>> ---
>> Changes from v1:
>>   - Fixed linker not finding VDSO symbols
>> ---
>>   arch/arm64/kernel/vdso.c          | 30 ++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/vdso/vdso.lds.S |  7 +++++++
>>   2 files changed, 37 insertions(+)
> 
> What is the reason for splitting the series into two patches?
> To me it looks like it should be one patch.

I've followed how tglx split his series ("x86/vdso: Prepare for robust 
futex unlock support", "x86/vdso: Implement 
__vdso_futex_robust_try_unlock()"), but I don't have a strong opinion on 
this matter, both options seems fine to me.

> 
>> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
>> index 592dd8668de4..f9c520a1c942 100644
>> --- a/arch/arm64/kernel/vdso.c
>> +++ b/arch/arm64/kernel/vdso.c
>> @@ -11,6 +11,7 @@
>>   #include <linux/clocksource.h>
>>   #include <linux/elf.h>
>>   #include <linux/err.h>
>> +#include <linux/futex.h>
>>   #include <linux/errno.h>
>>   #include <linux/gfp.h>
>>   #include <linux/kernel.h>
>> @@ -57,6 +58,33 @@ static struct vdso_abi_info vdso_info[] __ro_after_init = {
>>   #endif /* CONFIG_COMPAT_VDSO */
>>   };
>>   
>> +#ifdef CONFIG_FUTEX_ROBUST_UNLOCK
>> +static void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm)
>> +{
>> +	unsigned long vdso = (unsigned long) mm->context.vdso;
>> +	struct futex_mm_data *fd = &mm->futex;
>> +	uintptr_t success, end;
>> +
>> +	if (abi == VDSO_ABI_AA64) {
>> +		success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_success);
>> +		end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_end);
>> +
>> +		futex_set_vdso_cs_range(fd, 0, vdso, success, end, false);
> 
> Both VDSO_SYMBOL() and futex_set_vdso_cs_range() add the vdso base
> address to the symbol offsets. The value stored in .start_ip will be
> wrong. The fact that futex_set_vdso_cs_range() does the addition looks
> like an artifact of it being written for x86 first. IMO its interface
> should be changed not to do the addition internally.
> 

Got it, so for x86 we would need to explicitly add the base address on 
the caller and remove from futex_set_vdso_cs_range()

>> +	}
>> +
>> +#ifdef CONFIG_COMPAT_VDSO
>> +	if (abi == VDSO_ABI_AA32) {
>> +		success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_success);
>> +		end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_end);
>> +
>> +		futex_set_vdso_cs_range(fd, 1, vdso, success, end, true);
>> +	}
>> +#endif
>> +}
>> +#else
>> +static inline void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm) { }
>> +#endif /* CONFIG_FUTEX_ROBUST_UNLOCK */
>> +
>>   static int vdso_mremap(const struct vm_special_mapping *sm,
>>   		struct vm_area_struct *new_vma)
>>   {
> 
> (...)

Re: [PATCH RFC v2 1/2] arm64: vdso: Prepare for robust futex unlock support

[Thomas Weißschuh]

One more thing, sorry for the spam.

On 2026-04-24 15:56:00-0300, André Almeida wrote:
(...)

> +#ifdef CONFIG_FUTEX_ROBUST_UNLOCK
> +static void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm)
> +{
> +	unsigned long vdso = (unsigned long) mm->context.vdso;
> +	struct futex_mm_data *fd = &mm->futex;
> +	uintptr_t success, end;
> +
> +	if (abi == VDSO_ABI_AA64) {
> +		success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_success);
> +		end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_end);
> +
> +		futex_set_vdso_cs_range(fd, 0, vdso, success, end, false);
> +	}
> +
> +#ifdef CONFIG_COMPAT_VDSO
> +	if (abi == VDSO_ABI_AA32) {
> +		success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_success);
> +		end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_end);

The futex_list32_ symbols here are in the 64-bit vDSO. They are not
applicable for VDSO_ABI_AA32 processes.

> +
> +		futex_set_vdso_cs_range(fd, 1, vdso, success, end, true);
> +	}
> +#endif
> +}

(...)

[PATCH RFC v2 2/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()

[André Almeida]

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:

	__futex_list64_try_unlock_cs_start:
		ldxr	x3, [x0] // Load the value at *futex
		cmp	x1, x3   // Compare with TID
		b.ne	__futex_list64_try_unlock_cs_end
		stlxr	w1, xzr, [x0] // Try to clear *futex
		cbnz	w1, __futex_list64_try_unlock_cs_start
	__futex_list64_try_unlock_cs_success:
		str	xzr, [x2] // After clearing *futex, clear *op_pending
	__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
clear op_pending (if userspace didn't managed to) stored at x2.

Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
RFC:
 - Should I duplicate the explanation found in the x86 commit or can I just
 point to it?
 - Only LL/SC for now but I can add LSE later if this looks good
 - It the objdump I see that op_pending is store at x2. But how stable is this,
 how can I write it in a way that's always x2?
---
 arch/arm64/Kconfig                                 |  1 +
 arch/arm64/include/asm/futex_robust.h              | 35 +++++++++++++
 arch/arm64/kernel/vdso/Makefile                    |  9 +++-
 arch/arm64/kernel/vdso/vdso.lds.S                  |  4 ++
 .../kernel/vdso/vfutex_robust_list_try_unlock.c    | 59 ++++++++++++++++++++++
 5 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 427151a9db7f..e10cb97a51c7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -249,6 +249,7 @@ config ARM64
 	select HAVE_RELIABLE_STACKTRACE
 	select HAVE_POSIX_CPU_TIMERS_TASK_WORK
 	select HAVE_FUNCTION_ARG_ACCESS_API
+	select HAVE_FUTEX_ROBUST_UNLOCK
 	select MMU_GATHER_RCU_TABLE_FREE
 	select HAVE_RSEQ
 	select HAVE_RUST if RUSTC_SUPPORTS_ARM64
diff --git a/arch/arm64/include/asm/futex_robust.h b/arch/arm64/include/asm/futex_robust.h
new file mode 100644
index 000000000000..f2b7a2b15cb5
--- /dev/null
+++ b/arch/arm64/include/asm/futex_robust.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM64_FUTEX_ROBUST_H
+#define _ASM_ARM64_FUTEX_ROBUST_H
+
+#include <asm/ptrace.h>
+
+static __always_inline void __user *arm64_futex_robust_unlock_get_pop(struct pt_regs *regs)
+{
+	/*
+	 * RFC: According to the objdump bellow, x2 is the address of
+	 * op_pending. How stable is this?
+
+	 <__futex_list64_try_unlock_cs_start>:
+		ldxr	x3, [x0]
+		cmp	x1, x3
+		b.ne	d7c <__futex_list64_try_unlock_cs_end>  // b.any
+		stlxr	w1, xzr, [x0]
+		cbnz	w1, d64 <__futex_list64_try_unlock_cs_start>
+
+	<__futex_list64_try_unlock_cs_success>:
+		str	xzr, [x2]
+
+	<__futex_list64_try_unlock_cs_end>:
+		mov	w0, w3
+		ret
+	*/
+
+	return (regs->user_regs.pstate & PSR_Z_BIT) ? NULL
+		: (void __user *) regs->user_regs.regs[2];
+}
+
+#define arch_futex_robust_unlock_get_pop(regs)	\
+	arm64_futex_robust_unlock_get_pop(regs)
+
+#endif /* _ASM_ARM64_FUTEX_ROBUST_H */
diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index 7dec05dd33b7..a65893d8100e 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -9,7 +9,8 @@
 # Include the generic Makefile to check the built vdso.
 include $(srctree)/lib/vdso/Makefile.include
 
-obj-vdso := vgettimeofday.o note.o sigreturn.o vgetrandom.o vgetrandom-chacha.o
+obj-vdso := vgettimeofday.o note.o sigreturn.o vgetrandom.o vgetrandom-chacha.o \
+	    vfutex_robust_list_try_unlock.o
 
 # Build rules
 targets := $(obj-vdso) vdso.so vdso.so.dbg
@@ -45,9 +46,11 @@ CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
 
 CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_REMOVE_VDSO)
 CFLAGS_REMOVE_vgetrandom.o = $(CC_FLAGS_REMOVE_VDSO)
+CFLAGS_REMOVE_vfutex_robust_list_try_unlock.o = $(CC_FLAGS_REMOVE_VDSO)
 
 CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
 CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
+CFLAGS_vfutex_robust_list_try_unlock.o = $(CC_FLAGS_ADD_VDSO)
 
 ifneq ($(c-gettimeofday-y),)
   CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
@@ -57,6 +60,10 @@ ifneq ($(c-getrandom-y),)
   CFLAGS_vgetrandom.o += -include $(c-getrandom-y)
 endif
 
+ifneq ($(c-vfutex_robust_list_try_unlock-y),)
+  CFLAGS_vfutex_robust_list_try_unlock.o += -include $(c-vfutex_robust_list_try_unlock-y)
+endif
+
 targets += vdso.lds
 CPPFLAGS_vdso.lds += -P -C -U$(ARCH)
 
diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
index c532dae6ac8e..c324764cb6f9 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -104,6 +104,10 @@ VERSION
 		__kernel_clock_gettime;
 		__kernel_clock_getres;
 		__kernel_getrandom;
+		__vdso_futex_robust_list64_try_unlock;
+#ifdef CONFIG_COMPAT_VDSO
+		__vdso_futex_robust_list32_try_unlock;
+#endif
 	local: *;
 	};
 }
diff --git a/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
new file mode 100644
index 000000000000..e8a8fb22a2fa
--- /dev/null
+++ b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+#include <vdso/futex.h>
+#include <linux/stringify.h>
+
+#define LABEL(name, sz) __stringify(__futex_list##sz##_try_unlock_cs_##name)
+
+#define GLOBLS(sz) ".globl " LABEL(start, sz) ", " LABEL(success, sz) ", " LABEL(end, sz) "\n"
+
+__u32 __vdso_futex_robust_list64_try_unlock(__u32 *lock, __u32 tid, __u64 *pop)
+{
+	__u32 val, result;
+
+	asm volatile (
+		GLOBLS(64)
+		"	prfm pstl1strm, %[lock]			\n"
+		LABEL(start, 64)":				\n"
+		"	ldxr %[val], %[lock]			\n"
+		"	cmp %[tid], %[val]			\n"
+		"	bne " LABEL(end, 64)"			\n"
+		"	stlxr %w[result], xzr, %[lock]		\n"
+		"	cbnz %w[result], " LABEL(start, 64)"	\n"
+		LABEL(success, 64)":				\n"
+		"	str xzr, %[pop]				\n"
+		LABEL(end, 64)":				\n"
+
+		: [val] "=&r" (val), [result] "=r" (result)
+		: [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
+		: "memory"
+	);
+
+	return val;
+}
+
+#ifdef CONFIG_COMPAT_VDSO
+__u32 __vdso_futex_robust_list32_try_unlock(__u32 *lock, __u32 tid, __u32 *pop)
+{
+	__u32 val, result;
+
+	asm volatile (
+		GLOBLS(32)
+		"	prfm pstl1strm, %[lock]			\n"
+		LABEL(start, 32)":				\n"
+		"	ldxr %w[val], %[lock]			\n"
+		"	cmp %w[tid], %w[val]			\n"
+		"	bne " LABEL(end, 32)"			\n"
+		"	stlxr %w[result], wzr, %w[lock]		\n"
+		"	cbnz %w[result], " LABEL(start, 32)"	\n"
+		LABEL(success, 32)":				\n"
+		"	str wzr, %w[pop]			\n"
+		LABEL(end, 32)":				\n"
+
+		: [val] "=&r" (val), [result] "=r" (result)
+		: [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
+		: "memory"
+	);
+
+	return val;
+}
+#endif

-- 
2.53.0

Re: [PATCH RFC v2 2/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()

[Thomas Weißschuh]

On 2026-04-24 15:56:01-0300, André Almeida wrote:
(...)

> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
> RFC:
>  - Should I duplicate the explanation found in the x86 commit or can I just
>  point to it?
>  - Only LL/SC for now but I can add LSE later if this looks good
>  - It the objdump I see that op_pending is store at x2. But how stable is this,
>  how can I write it in a way that's always x2?
> ---
>  arch/arm64/Kconfig                                 |  1 +
>  arch/arm64/include/asm/futex_robust.h              | 35 +++++++++++++
>  arch/arm64/kernel/vdso/Makefile                    |  9 +++-
>  arch/arm64/kernel/vdso/vdso.lds.S                  |  4 ++
>  .../kernel/vdso/vfutex_robust_list_try_unlock.c    | 59 ++++++++++++++++++++++
>  5 files changed, 107 insertions(+), 1 deletion(-)

What about the actual 32-bit vDSO in arch/arm64/kernel/vdso32/ ?

(...)

> diff --git a/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
> new file mode 100644
> index 000000000000..e8a8fb22a2fa
> --- /dev/null
> +++ b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +#include <vdso/futex.h>
> +#include <linux/stringify.h>
> +
> +#define LABEL(name, sz) __stringify(__futex_list##sz##_try_unlock_cs_##name)

We should have some defines for these symbols. While they are not
userspace ABI, they will be used by the selftests.

> +#define GLOBLS(sz) ".globl " LABEL(start, sz) ", " LABEL(success, sz) ", " LABEL(end, sz) "\n"
> +
> +__u32 __vdso_futex_robust_list64_try_unlock(__u32 *lock, __u32 tid, __u64 *pop)
> +{
> +	__u32 val, result;
> +
> +	asm volatile (
> +		GLOBLS(64)
> +		"	prfm pstl1strm, %[lock]			\n"
> +		LABEL(start, 64)":				\n"
> +		"	ldxr %[val], %[lock]			\n"
> +		"	cmp %[tid], %[val]			\n"
> +		"	bne " LABEL(end, 64)"			\n"
> +		"	stlxr %w[result], xzr, %[lock]		\n"
> +		"	cbnz %w[result], " LABEL(start, 64)"	\n"
> +		LABEL(success, 64)":				\n"
> +		"	str xzr, %[pop]				\n"
> +		LABEL(end, 64)":				\n"
> +
> +		: [val] "=&r" (val), [result] "=r" (result)
> +		: [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
> +		: "memory"
> +	);

My clang 22.1.3 chokes on the assembly in this patch.

> +
> +	return val;
> +}
> +
> +#ifdef CONFIG_COMPAT_VDSO

I am wondering about the CONFIG_COMPAT{,_VDSO} dependency here.
As far as I know the list32 variant is meant to be used by code
emulators which run 32-bit code on a 64-bit kernel, for example FEX.
But these emulators don't actually seem to need CONFIG_COMPAT.
So the dependency does not look correct.
The space savings also should be irrelevant.

The x86 series from Thomas does the same, maybe he will read this
comment, otherwise I'll bring it up on his series, too.

> +__u32 __vdso_futex_robust_list32_try_unlock(__u32 *lock, __u32 tid, __u32 *pop)
> +{
> +	__u32 val, result;
> +
> +	asm volatile (
> +		GLOBLS(32)
> +		"	prfm pstl1strm, %[lock]			\n"
> +		LABEL(start, 32)":				\n"
> +		"	ldxr %w[val], %[lock]			\n"
> +		"	cmp %w[tid], %w[val]			\n"
> +		"	bne " LABEL(end, 32)"			\n"
> +		"	stlxr %w[result], wzr, %w[lock]		\n"
> +		"	cbnz %w[result], " LABEL(start, 32)"	\n"
> +		LABEL(success, 32)":				\n"
> +		"	str wzr, %w[pop]			\n"
> +		LABEL(end, 32)":				\n"
> +
> +		: [val] "=&r" (val), [result] "=r" (result)
> +		: [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
> +		: "memory"
> +	);
> +
> +	return val;
> +}
> +#endif

Re: [PATCH RFC v2 2/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()

[André Almeida]

Em 26/04/2026 15:30, Thomas Weißschuh escreveu:
> On 2026-04-24 15:56:01-0300, André Almeida wrote:
> (...)
> 
>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
>> ---
>> RFC:
>>   - Should I duplicate the explanation found in the x86 commit or can I just
>>   point to it?
>>   - Only LL/SC for now but I can add LSE later if this looks good
>>   - It the objdump I see that op_pending is store at x2. But how stable is this,
>>   how can I write it in a way that's always x2?
>> ---
>>   arch/arm64/Kconfig                                 |  1 +
>>   arch/arm64/include/asm/futex_robust.h              | 35 +++++++++++++
>>   arch/arm64/kernel/vdso/Makefile                    |  9 +++-
>>   arch/arm64/kernel/vdso/vdso.lds.S                  |  4 ++
>>   .../kernel/vdso/vfutex_robust_list_try_unlock.c    | 59 ++++++++++++++++++++++
>>   5 files changed, 107 insertions(+), 1 deletion(-)
> 
> What about the actual 32-bit vDSO in arch/arm64/kernel/vdso32/ ?
> 

Right, I missed that. Then I should move 
__vdso_futex_robust_list32_try_unlock() to arch/arm64/kernel/vdso32/ right?

> (...)
> 
>> diff --git a/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
>> new file mode 100644
>> index 000000000000..e8a8fb22a2fa
>> --- /dev/null
>> +++ b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
>> @@ -0,0 +1,59 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +#include <vdso/futex.h>
>> +#include <linux/stringify.h>
>> +
>> +#define LABEL(name, sz) __stringify(__futex_list##sz##_try_unlock_cs_##name)
> 
> We should have some defines for these symbols. While they are not
> userspace ABI, they will be used by the selftests.
> 

Do you mean to have this defined at include/uapi/linux/futex.h?

>> +#define GLOBLS(sz) ".globl " LABEL(start, sz) ", " LABEL(success, sz) ", " LABEL(end, sz) "\n"
>> +
>> +__u32 __vdso_futex_robust_list64_try_unlock(__u32 *lock, __u32 tid, __u64 *pop)
>> +{
>> +	__u32 val, result;
>> +
>> +	asm volatile (
>> +		GLOBLS(64)
>> +		"	prfm pstl1strm, %[lock]			\n"
>> +		LABEL(start, 64)":				\n"
>> +		"	ldxr %[val], %[lock]			\n"
>> +		"	cmp %[tid], %[val]			\n"
>> +		"	bne " LABEL(end, 64)"			\n"
>> +		"	stlxr %w[result], xzr, %[lock]		\n"
>> +		"	cbnz %w[result], " LABEL(start, 64)"	\n"
>> +		LABEL(success, 64)":				\n"
>> +		"	str xzr, %[pop]				\n"
>> +		LABEL(end, 64)":				\n"
>> +
>> +		: [val] "=&r" (val), [result] "=r" (result)
>> +		: [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
>> +		: "memory"
>> +	);
> 
> My clang 22.1.3 chokes on the assembly in this patch.
> 

Do you mind sharing the output?

>> +
>> +	return val;
>> +}
>> +
>> +#ifdef CONFIG_COMPAT_VDSO
> 
> I am wondering about the CONFIG_COMPAT{,_VDSO} dependency here.
> As far as I know the list32 variant is meant to be used by code
> emulators which run 32-bit code on a 64-bit kernel, for example FEX.
> But these emulators don't actually seem to need CONFIG_COMPAT.
> So the dependency does not look correct.
> The space savings also should be irrelevant.

Right, good catch. In the new syscall I had to do something similar[1], 
to expose the 32-bit functions to 64-bit kernels as well, and not hide 
them behind CONFIG_COMPAT.

[1] 
https://lore.kernel.org/lkml/20251122-tonyk-robust_futex-v6-2-05fea005a0fd@igalia.com/

> 
> The x86 series from Thomas does the same, maybe he will read this
> comment, otherwise I'll bring it up on his series, too.
> 
>> +__u32 __vdso_futex_robust_list32_try_unlock(__u32 *lock, __u32 tid, __u32 *pop)
>> +{
>> +	__u32 val, result;
>> +
>> +	asm volatile (
>> +		GLOBLS(32)
>> +		"	prfm pstl1strm, %[lock]			\n"
>> +		LABEL(start, 32)":				\n"
>> +		"	ldxr %w[val], %[lock]			\n"
>> +		"	cmp %w[tid], %w[val]			\n"
>> +		"	bne " LABEL(end, 32)"			\n"
>> +		"	stlxr %w[result], wzr, %w[lock]		\n"
>> +		"	cbnz %w[result], " LABEL(start, 32)"	\n"
>> +		LABEL(success, 32)":				\n"
>> +		"	str wzr, %w[pop]			\n"
>> +		LABEL(end, 32)":				\n"
>> +
>> +		: [val] "=&r" (val), [result] "=r" (result)
>> +		: [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
>> +		: "memory"
>> +	);
>> +
>> +	return val;
>> +}
>> +#endif

Re: [PATCH RFC v2 2/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()

[Thomas Weißschuh]

On 2026-04-27 13:26:41-0300, André Almeida wrote:
> Em 26/04/2026 15:30, Thomas Weißschuh escreveu:
> > On 2026-04-24 15:56:01-0300, André Almeida wrote:
> > (...)
> > 
> > > Signed-off-by: André Almeida <andrealmeid@igalia.com>
> > > ---
> > > RFC:
> > >   - Should I duplicate the explanation found in the x86 commit or can I just
> > >   point to it?
> > >   - Only LL/SC for now but I can add LSE later if this looks good
> > >   - It the objdump I see that op_pending is store at x2. But how stable is this,
> > >   how can I write it in a way that's always x2?
> > > ---
> > >   arch/arm64/Kconfig                                 |  1 +
> > >   arch/arm64/include/asm/futex_robust.h              | 35 +++++++++++++
> > >   arch/arm64/kernel/vdso/Makefile                    |  9 +++-
> > >   arch/arm64/kernel/vdso/vdso.lds.S                  |  4 ++
> > >   .../kernel/vdso/vfutex_robust_list_try_unlock.c    | 59 ++++++++++++++++++++++
> > >   5 files changed, 107 insertions(+), 1 deletion(-)
> > 
> > What about the actual 32-bit vDSO in arch/arm64/kernel/vdso32/ ?
> > 
> 
> Right, I missed that. Then I should move
> __vdso_futex_robust_list32_try_unlock() to arch/arm64/kernel/vdso32/ right?

Are 64-bit processes supposed to have the list32 variant already?
If so, you need this function, *with the same name* in both vDSOs.
In any case for the 32-bit vDSO you'll need to extend the build system
to create a vdso32-offsets.h. If you have the list32 variant twice, use
differently named VDSO{,32}_ constants to refer to them from kernel code.

> > (...)
> > 
> > > diff --git a/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
> > > new file mode 100644
> > > index 000000000000..e8a8fb22a2fa
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
> > > @@ -0,0 +1,59 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +#include <vdso/futex.h>
> > > +#include <linux/stringify.h>
> > > +
> > > +#define LABEL(name, sz) __stringify(__futex_list##sz##_try_unlock_cs_##name)
> > 
> > We should have some defines for these symbols. While they are not
> > userspace ABI, they will be used by the selftests.
> > 
> 
> Do you mean to have this defined at include/uapi/linux/futex.h?

No, they are not UAPI. It should go into include/vdso/futex.h.

> > > +#define GLOBLS(sz) ".globl " LABEL(start, sz) ", " LABEL(success, sz) ", " LABEL(end, sz) "\n"
> > > +
> > > +__u32 __vdso_futex_robust_list64_try_unlock(__u32 *lock, __u32 tid, __u64 *pop)
> > > +{
> > > +	__u32 val, result;
> > > +
> > > +	asm volatile (
> > > +		GLOBLS(64)
> > > +		"	prfm pstl1strm, %[lock]			\n"
> > > +		LABEL(start, 64)":				\n"
> > > +		"	ldxr %[val], %[lock]			\n"
> > > +		"	cmp %[tid], %[val]			\n"
> > > +		"	bne " LABEL(end, 64)"			\n"
> > > +		"	stlxr %w[result], xzr, %[lock]		\n"
> > > +		"	cbnz %w[result], " LABEL(start, 64)"	\n"
> > > +		LABEL(success, 64)":				\n"
> > > +		"	str xzr, %[pop]				\n"
> > > +		LABEL(end, 64)":				\n"
> > > +
> > > +		: [val] "=&r" (val), [result] "=r" (result)
> > > +		: [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
> > > +		: "memory"
> > > +	);
> > 
> > My clang 22.1.3 chokes on the assembly in this patch.
> > 
> 
> Do you mind sharing the output?

arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:26:18: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
   26 |                 : [val] "=&r" (val), [result] "=r" (result)
      |                                ^
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:17:10: note: use constraint modifier "w"
   17 |                 "       ldxr %[val], %[lock]                    \n"
      |                              ^~~~~~
      |                              %w[val]
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:27:16: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
   27 |                 : [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
      |                              ^
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:18:9: note: use constraint modifier "w"
   18 |                 "       cmp %[tid], %[val]                      \n"
      |                             ^~~~~~
      |                             %w[tid]
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:26:18: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
   26 |                 : [val] "=&r" (val), [result] "=r" (result)
      |                                ^
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:18:17: note: use constraint modifier "w"
   18 |                 "       cmp %[tid], %[val]                      \n"
      |                                     ^~~~~~
      |                                     %w[val]
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:40:3: error: invalid operand in inline asm: '.globl __futex_list32_try_unlock_cs_start, __futex_list32_try_unlock_cs_success, __futex_list32_try_unlock_cs_end
	prfm pstl1strm, $3			
__futex_list32_try_unlock_cs_start:				
	ldxr ${0:w}, $3			
	cmp ${2:w}, ${0:w}			
	bne __futex_list32_try_unlock_cs_end			
	stlxr ${1:w}, wzr, ${3:w}		
	cbnz ${1:w}, __futex_list32_try_unlock_cs_start	
__futex_list32_try_unlock_cs_success:				
	str wzr, ${4:w}			
__futex_list32_try_unlock_cs_end:				
'
   40 |                 GLOBLS(32)
      |                 ^
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:7:20: note: expanded from macro 'GLOBLS'
    7 | #define GLOBLS(sz) ".globl " LABEL(start, sz) ", " LABEL(success, sz) ", " LABEL(end, sz) "\n"
      |                    ^
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:40:3: error: invalid operand in inline asm: '.globl __futex_list32_try_unlock_cs_start, __futex_list32_try_unlock_cs_success, __futex_list32_try_unlock_cs_end
	prfm pstl1strm, $3			
__futex_list32_try_unlock_cs_start:				
	ldxr ${0:w}, $3			
	cmp ${2:w}, ${0:w}			
	bne __futex_list32_try_unlock_cs_end			
	stlxr ${1:w}, wzr, ${3:w}		
	cbnz ${1:w}, __futex_list32_try_unlock_cs_start	
__futex_list32_try_unlock_cs_success:				
	str wzr, ${4:w}			
__futex_list32_try_unlock_cs_end:				
'
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:7:20: note: expanded from macro 'GLOBLS'
    7 | #define GLOBLS(sz) ".globl " LABEL(start, sz) ", " LABEL(success, sz) ", " LABEL(end, sz) "\n"
      |                    ^
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:46:4: error: unknown token in expression
   46 |                 "       stlxr %w[result], wzr, %w[lock]         \n"
      |                  ^
<inline asm>:7:19: note: instantiated into assembly here
    7 |         stlxr w9, wzr,          
      |                                 ^
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:46:4: error: invalid operand
   46 |                 "       stlxr %w[result], wzr, %w[lock]         \n"
      |                  ^
<inline asm>:7:19: note: instantiated into assembly here
    7 |         stlxr w9, wzr,          
      |                                 ^
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:49:4: error: unknown token in expression
   49 |                 "       str wzr, %w[pop]                        \n"
      |                  ^
<inline asm>:10:14: note: instantiated into assembly here
   10 |         str wzr,                        
      |                                         ^
arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c:49:4: error: invalid operand
   49 |                 "       str wzr, %w[pop]                        \n"
      |                  ^
<inline asm>:10:14: note: instantiated into assembly here
   10 |         str wzr,                        
      |                                         ^
3 warnings and 6 errors generated.

> > > +
> > > +	return val;
> > > +}
> > > +
> > > +#ifdef CONFIG_COMPAT_VDSO
> > 
> > I am wondering about the CONFIG_COMPAT{,_VDSO} dependency here.
> > As far as I know the list32 variant is meant to be used by code
> > emulators which run 32-bit code on a 64-bit kernel, for example FEX.
> > But these emulators don't actually seem to need CONFIG_COMPAT.
> > So the dependency does not look correct.
> > The space savings also should be irrelevant.
> 
> Right, good catch. In the new syscall I had to do something similar[1], to
> expose the 32-bit functions to 64-bit kernels as well, and not hide them
> behind CONFIG_COMPAT.
> 
> [1] https://lore.kernel.org/lkml/20251122-tonyk-robust_futex-v6-2-05fea005a0fd@igalia.com/

If the regular system calls don't currently support a 32-bit robust list
on 64-bit systems I am wondering why tglx added them to the x86_64 vDSO.
They seem pointless for now. Maybe to be ready for your series?

Also on x86_64, if wine WoW64 should end up using the 32-bit robust list
from a 64-bit process, the CONFIG_COMPAT dependency looks incorrect.

> > The x86 series from Thomas does the same, maybe he will read this
> > comment, otherwise I'll bring it up on his series, too.
> > 
> > > +__u32 __vdso_futex_robust_list32_try_unlock(__u32 *lock, __u32 tid, __u32 *pop)
> > > +{
> > > +	__u32 val, result;
> > > +
> > > +	asm volatile (
> > > +		GLOBLS(32)
> > > +		"	prfm pstl1strm, %[lock]			\n"
> > > +		LABEL(start, 32)":				\n"
> > > +		"	ldxr %w[val], %[lock]			\n"
> > > +		"	cmp %w[tid], %w[val]			\n"
> > > +		"	bne " LABEL(end, 32)"			\n"
> > > +		"	stlxr %w[result], wzr, %w[lock]		\n"
> > > +		"	cbnz %w[result], " LABEL(start, 32)"	\n"
> > > +		LABEL(success, 32)":				\n"
> > > +		"	str wzr, %w[pop]			\n"
> > > +		LABEL(end, 32)":				\n"
> > > +
> > > +		: [val] "=&r" (val), [result] "=r" (result)
> > > +		: [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
> > > +		: "memory"
> > > +	);
> > > +
> > > +	return val;
> > > +}
> > > +#endif
> 

Re: [PATCH RFC v2 0/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()

[Sebastian Andrzej Siewior]

On 2026-04-24 15:55:59 [-0300], André Almeida wrote:
> Hi folks,
Hi,

> This is my take on implementing the new vDSO for unlocking a robust futex in
> arm64. If you don't know what's that, Thomas wrote a good summary,
> including the motivation for this work and the x86 implementation:
> 
>    https://lore.kernel.org/lkml/878qb89g7b.ffs@tglx/
> 
> There are some loose ends in my patchset so I'm sending as a RFC to ask
> some questions:
> 
>  - If the process is interrupted between the labels, we need to check the
>  conditional flags and clear the op_pending address from the register. Using
>  objdump I see that op_pending addr is being stored at x2, but I suspect that
>  this isn't stable, so I need to figure out how to make sure that the address
>  will always be stored in the same register.
>  - So far I have implemented only the LL/SC version to make review easier, but I
>  can do the LSE version as well.

I am a bit behind here. In the meantime, were you able to check it with
	https://lore.kernel.org/all/20260404093939.7XgeW_54@linutronix.de/
?

Sebastian