Use __u128 in arm64 UAPI headers
Subsystems (2)
Will Deacon
maintainerv2 cover Use __u128 in arm64 UAPI headers
Hi folks,
This is version two of the patch I previously sent here:
https://lore.kernel.org/r/[email protected]
I even briefly queued that version up, but it exploded spectacularly when building the kselftests for arm64 [1] [2]. So the only change since v1 is the addition of a preliminary patch that adds the '__u128' typedef to the private copy of linux/types.h used by the tools/ directory.
I plan to take this all via the arm64 tree unless anybody objects.
Cheers,
Will
[1] https://lore.kernel.org/r/[email protected]
[2] https://lore.kernel.org/r/[email protected]
--->8
Will Deacon (2):
tools: linux/types.h: Add 128-bit integer types for arm64 UAPI
structures
arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers
arch/arm64/include/uapi/asm/ptrace.h | 12 ++++++------ arch/arm64/include/uapi/asm/sigcontext.h | 6 +++--- tools/include/linux/types.h | 5 +++++ 3 files changed, 14 insertions(+), 9 deletions(-)
Signature · 1 line
2.55.0.rc0.799.gd6f94ed593-goog
Will Deacon
maintainerPATCH v2 1/2 tools: linux/types.h: Add 128-bit integer types for arm64 UAPI structures
The arm64 UAPI exposes some 128-bit integer types to represent things such as fpsimd registers in the sigcontext. In preparation for defining these using the '__u128' typedef implemented by uapi/linux/types.h, copy that typedef over to the private linux/types.h header used by the tools directory.
--- tools/include/linux/types.h | 5 +++++ 1 file changed, 5 insertions(+)
tools/include/linux/types.h +5 -0
@@ -23,6 +23,11 @@ typedef enum {__GFP_HIGH } gfp_t; +#ifdef __SIZEOF_INT128__ +typedef __signed__ __int128 __s128 __attribute__((aligned(16))); +typedef unsigned __int128 __u128 __attribute__((aligned (16 ))); +#endif +/* * We define u64 as uint64_t for every architecture * so that we can print it with "%"PRIx64 without getting warnings.
Signature · 1 line
2.55.0.rc0.799.gd6f94ed593-goog
Re: [PATCH v2 1/2] tools: linux/types.h: Add 128-bit integer types for arm64 UAPI structures
Hi,
Please consider this for all supported stable/LTS kernels.
Without this commit, older kernel trees will fail to build tools on systems running newer kernel headers.
Upstream commit:
10a47fb67340 ("tools: linux/types.h: Add 128-bit integer types for arm64 UAPI structures")
Thanks,
Quoted 30 lines · Will Deacon
The arm64 UAPI exposes some 128-bit integer types to represent things such as fpsimd registers in the sigcontext. In preparation for defining these using the '
__u128' typedef implemented byuapi/linux/types.h, copy that typedef over to the privatelinux/types.hheader used by the tools directory.Cc Arnd Bergmann <[email protected]>Cc Arnaldo Carvalho de Melo <[email protected]>Cc David Matlack <[email protected]>Signed-off-by Will Deacon <[email protected]>--- tools/include/linux/types.h | 5 +++++ 1 file changed, 5 insertions(+)tools/include/linux/types.h +5
-0@@ -23,6 +23,11 @@ typedef enum {__GFP_HIGH } gfp_t; +#ifdef __SIZEOF_INT128__ +typedef __signed__ __int128 __s128 __attribute__((aligned(16))); +typedef unsigned __int128 __u128 __attribute__((aligned (16 ))); +#endif +/* * We define u64 as uint64_t for every architecture * so that we can print it with "%"PRIx64 without getting warnings.
Will Deacon
maintainerPATCH v2 2/2 arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers
In reply to Will DeaconThe arm64 UAPI exposes '__uint128_t' types in the members of 'struct user_fpsimd_state', 'struct user_pac_address_keys' and in the signal frame via 'struct fpsimd_context'. Since the alignment of such a type appears to be non-portable (16 bytes on arm64, 8 bytes on s390), prefer the '__u128' typedef from uapi/linux/types.h, which makes the alignment explicit and allows the definitions to be reused by other host architectures.
--- arch/arm64/include/uapi/asm/ptrace.h | 12 ++++++------ arch/arm64/include/uapi/asm/sigcontext.h | 6 +++--- 2 files changed, 9 insertions(+), 9 deletions(-)
arch/arm64/include/uapi/asm/ptrace.h +6 -6
@@ -93,7 +93,7 @@ struct user_pt_regs { };struct user_fpsimd_state { -__uint128_t vregs[32 ]; +__u128 vregs[32 ];__u32 fpsr;__u32 fpcr;__u32 __reserved[2 ];
@@ -258,14 +258,14 @@ struct user_pac_mask {/* pointer authentication keys (NT_ARM_PACA_KEYS, NT_ARM_PACG_KEYS) */ struct user_pac_address_keys { -__uint128_t apiakey; -__uint128_t apibkey; -__uint128_t apdakey; -__uint128_t apdbkey; +__u128 apiakey; +__u128 apibkey; +__u128 apdakey; +__u128 apdbkey; };struct user_pac_generic_keys { -__uint128_t apgakey; +__u128 apgakey; };/* ZA state (NT_ARM_ZA) */
arch/arm64/include/uapi/asm/sigcontext.h +3 -3
@@ -78,7 +78,7 @@ struct fpsimd_context {struct _aarch64_ctx head;__u32 fpsr;__u32 fpcr; -__uint128_t vregs[32 ]; +__u128 vregs[32 ]; };/*
@@ -266,8 +266,8 @@ struct gcs_context {* - ---- ----------- * REGS the entire SVE context * -* ZREGS __uint128_t[SVE_NUM_ZREGS][vq] all Z-registers -* ZREG __uint128_t[vq] individual Z-register Zn +* ZREGS __u128[SVE_NUM_ZREGS][vq] all Z-registers +* ZREG __u128[vq] individual Z-register Zn * * PREGS uint16_t[SVE_NUM_PREGS][vq] all P-registers * PREG uint16_t[vq] individual P-register Pn
Signature · 1 line
2.55.0.rc0.799.gd6f94ed593-goog
Quoted 10 lines · Will Deacon
This is version two of the patch I previously sent here:
https://lore.kernel.org/r/[email protected]
I even briefly queued that version up, but it exploded spectacularly when building the kselftests for arm64 [1] [2]. So the only change since v1 is the addition of a preliminary patch that adds the '
__u128' typedef to the private copy oflinux/types.hused by thetools/directory.[...]
Applied to arm64 (for-next/uapi), thanks!
[1/2] tools: linux/types.h: Add 128-bit integer types for arm64 UAPI structures
https://git.kernel.org/arm64/c/10a47fb67340 [2/2] arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers https://git.kernel.org/arm64/c/d4bf9e08d412
Cheers,
Signature · 5 lines
Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev
Hi,
Quoted 4 lines · Will Deacon
Hi folks,
This is version two of the patch I previously sent here:
Quoted 8 lines
https://lore.kernel.org/r/[email protected]I even briefly queued that version up, but it exploded spectacularly when building the kselftests for arm64 [1] [2]. So the only change since v1 is the addition of a preliminary patch that adds the '
__u128' typedef to the private copy oflinux/types.hused by thetools/directory.I plan to take this all via the arm64 tree unless anybody objects.
This seems to be creating a interesting situation that the follow-on commit:10a47fb67340 tools: linux/types.h: Add 128-bit integer types for arm64 UAPI structures
Is missing from older kernel tooling/etc, which means the tools that end up pulling this header in won't build on machines running 7.3 kernel headers.
AKA, build/install master, switch back to an older branch and discover say bpftool won't build anymore.
Thanks,
Quoted 31 lines
Cheers,
Will
[1] https://lore.kernel.org/r/[email protected]
[2] https://lore.kernel.org/r/[email protected]Cc Arnd Bergmann <[email protected]>Cc Arnaldo Carvalho de Melo <[email protected]>Cc Nick Desaulniers <[email protected]>Cc David Matlack <[email protected]>Cc Steffen Eiden <[email protected]>Cc Andreas Grapentin <[email protected]>Cc Catalin Marinas <[email protected]>Cc Dave Martin <[email protected]>Cc Mark Rutland <[email protected]>Cc Marc Zyngier <[email protected]>--->8
Will Deacon (2):
tools:linux/types.h: Add 128-bit integer types for arm64 UAPI
structures
arm64: uapi: Use__u128instead of__uint128_tin UAPI headersarch/arm64/include/uapi/asm/ptrace.h | 12 ++++++------ arch/arm64/include/uapi/asm/sigcontext.h | 6 +++--- tools/include/linux/types.h | 5 +++++ 3 files changed, 14 insertions(+), 9 deletions(-)
Will Deacon
maintainerQuoted 16 lines · Jeremy Linton
Quoted 10 lines · Will Deacon
This is version two of the patch I previously sent here:
https://lore.kernel.org/r/[email protected]I even briefly queued that version up, but it exploded spectacularly when building the kselftests for arm64 [1] [2]. So the only change since v1 is the addition of a preliminary patch that adds the '
__u128' typedef to the private copy oflinux/types.hused by thetools/directory.I plan to take this all via the arm64 tree unless anybody objects.
This seems to be creating a interesting situation that the follow-on commit:
10a47fb67340tools:linux/types.h: Add 128-bit integer types for arm64 UAPI structures
Quoted 5 lines
Is missing from older kernel tooling/etc, which means the tools that end up pulling this header in won't build on machines running 7.3 kernel headers.
AKA, build/install master, switch back to an older branch and discover say bpftool won't build anymore.
Ah, I guess we need to backport 10a47fb67340 to stable, then?
Will