Re: [PATCH v3 1/5] arm64: vdso: Prepare for robust futex unlock support
From: André Almeida
Date: Mon Jun 01 2026 - 12:33:08 EST
Em 29/05/2026 14:16, Thomas Weißschuh escreveu:
On 2026-05-29 13:33:53-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@xxxxxxxxxx>
---
Notes:
- The diff futex_set_vdso_cs_range() should happen in the commit that
introduced it, and rebase will clear it from here
- So far I couldn't figure out why current->rseq.event.user_irq is never set in
aarch64
Why not put these unrelated changes into their own commits?
It makes reviewing and integrating it into the original series easier.
OK, I will separated them for a next version. But hopefully those changes won't be needed for the next one.
v3:
- Fix adding vdso base addr twice
- Call vdso_futex_robust_unlock_update_ips() on remap as well
v2:
- Fixed linker not finding VDSO symbols
---
arch/arm64/kernel/vdso.c | 25 +++++++++++++++++++++++++
arch/arm64/kernel/vdso/vdso.lds.S | 5 +++++
arch/x86/entry/vdso/vma.c | 4 ++--
include/linux/futex.h | 13 ++-----------
4 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 592dd8668de4..76f22ea8e181 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,11 +58,31 @@ 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, success, end, false);
+ }
+}
+#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)
{
current->mm->context.vdso = (void *)new_vma->vm_start;
+ vdso_futex_robust_unlock_update_ips(VDSO_ABI_AA64, current->mm);
+
return 0;
}
@@ -134,6 +155,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:
@@ -159,6 +182,8 @@ static int aarch32_sigpage_mremap(const struct vm_special_mapping *sm,
{
current->mm->context.sigpage = (void *)new_vma->vm_start;
+ vdso_futex_robust_unlock_update_ips(VDSO_ABI_AA32, current->mm);
This is for the sigpage remap, not the vDSO, is it really necessary?
If yes it should be part of the later VDSO_ABI_AA32 patch IMO.
Ok, I don't think it moves the vDSO indeed.
If there is a way for a 64-bit application to call 32-bit syscalls then
the 64-bit vDSO also needs the 32-bit functions. See:
[0] https://lore.kernel.org/lkml/875x4zw4bp.ffs@tglx/
I believe this is true for x86, but not for aarch64. Currently x86 apps running on top of arm64 have no way to register a 32 bit list, but this will change with the upcoming multi list feature.
return 0;
}
diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
index 52314be29191..8633aafe6b81 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -104,6 +104,7 @@ VERSION
__kernel_clock_gettime;
__kernel_clock_getres;
__kernel_getrandom;
+ __vdso_futex_robust_list64_try_unlock;
Guard behind CONFIG_FUTEX_ROBUST_UNLOCK ?
ld.lld fails when a function mentioned in the linker script is missing.
Yes, you are right, thanks for the review!
local: *;
};
}
@@ -112,3 +113,7 @@ VERSION
* Make the sigreturn code visible to the kernel.
*/
VDSO_sigtramp = __kernel_rt_sigreturn;
+
+VDSO_futex_list64_try_unlock_cs_start = __futex_list64_try_unlock_cs_start;
+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;
(...)