Re: [PATCH v5 04/24] arm64: elf: Move relocation constants to UAPI

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Exporting R_AARCH64_NONE as 256 to UAPI conflicts with the standard userspace <elf.h>, causing macro redefinition errors and silent logic bugs.
--

commit c95aba5e089f1a024a83cb3e067c1b0d44928541
Author: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

arm64: elf: Move relocation constants to UAPI

This commit moves AArch64 static relocation constants from the kernel-private
architecture-specific header to the UAPI. This is intended to make these
constants available for cross-platform userspace applications.

> diff --git a/include/uapi/linux/elf-r.h b/include/uapi/linux/elf-r.h
> index 001884641e770..cf931fc05afa1 100644
> --- a/include/uapi/linux/elf-r.h
> +++ b/include/uapi/linux/elf-r.h
[ ... ]
> @@ -61,4 +61,56 @@
>  #define R_ARM_THM_MOVW_PREL_NC	49
>  #define R_ARM_THM_MOVT_PREL	50
>  
> +/* AArch64 static relocation types */
> +
> +/* Miscellaneous. */
> +#define R_AARCH64_NONE			256

[Severity: Critical]
Does exporting this internal value to the UAPI conflict with the standard
AArch64 ELF ABI?

The standard userspace <elf.h> (such as the one provided by glibc) defines
R_AARCH64_NONE as 0, which is explicitly required by the AArch64 ELF ABI.
Exposing the kernel's internal legacy value of 256 here causes macro
redefinition errors for programs including both headers.

Additionally, applications strictly relying on this new UAPI might silently
check for 256 instead of 0, resulting in a failure to handle standard null
relocations emitted by toolchains.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908-vdso-absolute-reloc-v5-0-3a93791af1cf@linutronix.de?part=4