Re: [PATCH v21 14/15] tools: Synchronise the kernel esr.h

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] tools: incorrect mapping of ESR_ELx_FSC_ADDRSZ_nL for level -1
--

commit 29c713adc7b9f4531e116d3021bff33ab6d602a4
Author: Mark Brown <broonie@kernel.org>

tools: Synchronise the kernel esr.h

This commit synchronizes the tools version of the arm64 esr.h header with
the main kernel header to pick up definitions for GCS.

> diff --git a/tools/arch/arm64/include/asm/esr.h b/tools/arch/arm64/include/asm/esr.h
> index f3c6403e5ef2b..24c6ebe3fd416 100644
> --- a/tools/arch/arm64/include/asm/esr.h
> +++ b/tools/arch/arm64/include/asm/esr.h
[ ... ]
> @@ -119,6 +123,16 @@
>  #define ESR_ELx_FSC_SEA_TTW(n)	(0x14 + (n))
>  #define ESR_ELx_FSC_SECC	(0x18)
>  #define ESR_ELx_FSC_SECC_TTW(n)	(0x1c + (n))
> +#define ESR_ELx_FSC_EXCL_ATOMIC	(0x35)
> +#define ESR_ELx_FSC_ADDRSZ	(0x00)
> +
> +/*
> + * Annoyingly, the negative levels for Address size faults aren't laid out
> + * contiguously (or in the desired order)
> + */
> +#define ESR_ELx_FSC_ADDRSZ_nL(n)	((n) == -1 ? 0x25 : 0x2C)

[Severity: Medium]
Does this ESR_ELx_FSC_ADDRSZ_nL macro incorrectly map level -1 Address
Size faults to 0x25 instead of 0x29?

If tools/arch/arm64/include/asm/esr.h is meant to be synchronized with the
kernel header, diverging here causes user-space tools (such as KVM selftests
or perf) to misdecode or incorrectly inject Address Size faults for level -1.
Any tool compiling against this header and invoking ESR_ELx_FSC_ADDRSZ_L(-1)
would receive 0x25 rather than the correct hardware encoding 0x29.

> +#define ESR_ELx_FSC_ADDRSZ_L(n)		((n) < 0 ? ESR_ELx_FSC_ADDRSZ_nL(n) : \
> +						   (ESR_ELx_FSC_ADDRSZ + (n)))
>  
>  /* Status codes for individual page table levels */
>  #define ESR_ELx_FSC_ACCESS_L(n)	(ESR_ELx_FSC_ACCESS + (n))

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930-arm64-gcs-v21-0-3556644cd927@kernel.org?part=14