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

[Florian Weimer <fweimer@redhat.com>]

* André Almeida:

> 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@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.

Sorry, I was confused about how this is expected to work.

Florian