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

André Almeida andrealmeid at igalia.com
Wed Apr 22 05:46:53 PDT 2026


Hi Florian,

Em 17/04/2026 12:08, Florian Weimer escreveu:
> * 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 at igalia.com>
>> ---
>> RFC: Those symbols can't be found by the linker after patch 2/2, it fails with:
>>
>> ld: arch/arm64/kernel/vdso.o: in function `vdso_futex_robust_unlock_update_ips':
>> arch/arm64/kernel/vdso.c:72:(.text+0x200): undefined reference to `__futex_list64_try_unlock_cs_success'
>> ld: arch/arm64/kernel/vdso.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__futex_list64_try_unlock_cs_success' which may bind externally can not be used when making a shared object; recompile with -fPIC
>> arch/arm64/kernel/vdso.c:72:(.text+0x200): dangerous relocation: unsupported relocation
> 
> I think your GLOBLS definition adds a 64 suffix.  That shouldn't be
> necessary on AArch64.  It's not reflected in the references, so you end
> up with an undefined symbol error.
> 

Why aarch64 doesn't need the 64 suffix? objdump shows that the final 
label name is __futex_list64_try_unlock_cs_success, which should match 
what the linker is trying to find, AFAIC.

	André



More information about the linux-arm-kernel mailing list