arm64: uapi: Use u128 instead of uint128_t in UAPI headers

PATCH Applied Will Deacon 4 participants 5 messages Jun 19 – Jun 23 arm64

Share & tools

Will Deacon

author maintainer

2026-06-19 13:08 UTC #0 lore raw

PATCH 1/1 arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers

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

Cc Arnd Bergmann <[email protected]>

Cc Nick Desaulniers <[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]>

Signed-off-by Will Deacon <[email protected]>

---

This aims to help a little with the s390/arm64 KVM series at:

https://lore.kernel.org/r/[email protected]

by allowing the relevant parts of the arm64 UAPI to be used directly by s390 rather than copied and modified.

I think it's a straightforward change, but the only thing that makes me pause for thought is whether there are toolchains out there which accept __uint128_t but not __int128. Then again, if that crops up as an issue we can probably just tweak the typedef we have in uapi/linux/types.h.

 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

index 6fed93fb2536..15649a253a57 100644
@@ -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

index e29bf3e2d0cc..d250ca7a1d46 100644
@@ -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.738.g0c8ab3ebcc-goog

Arnd Bergmann

Reviewed-by on v1 1/1

2026-06-19 13:52 UTC #1 lore raw

Quoted 8 lines · Will Deacon

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

Quoted 9 lines

Cc Arnd Bergmann <[email protected]>
Cc Nick Desaulniers <[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]>
Signed-off-by Will Deacon <[email protected]>

Reviewed-by Arnd Bergmann <[email protected]>

Quoted 4 lines

I think it's a straightforward change, but the only thing that makes me pause for thought is whether there are toolchains out there which accept __uint128_t but not __int128. Then again, if that crops up as an issue we can probably just tweak the typedef we have in uapi/linux/types.h.

clang-3.1 and gcc-4.6 support both and are 15 years old, older versions only do __uint128_t. I agree that this should be fine.

Arnd

Marc Zyngier

Reviewed-by on v1 1/1

2026-06-19 14:09 UTC #2 lore raw

In reply to Will Deacon

Quoted 9 lines · Will Deacon

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

Quoted 9 lines

Cc Arnd Bergmann <[email protected]>
Cc Nick Desaulniers <[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]>
Signed-off-by Will Deacon <[email protected]>

FWIW:

Reviewed-by Marc Zyngier <[email protected]>

M.

Signature · 1 line

Without deviation from the norm, progress is not possible.

Mark Rutland

reviewer Acked-by on v1 1/1

2026-06-19 14:52 UTC #3 lore raw

In reply to Will Deacon

Quoted 23 lines · Will Deacon

The 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.
Cc Arnd Bergmann <[email protected]>
Cc Nick Desaulniers <[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]>
Signed-off-by Will Deacon <[email protected]>
---
This aims to help a little with the s390/arm64 KVM series at:
https://lore.kernel.org/r/[email protected]

Quoted 7 lines

by allowing the relevant parts of the arm64 UAPI to be used directly by s390 rather than copied and modified.
I think it's a straightforward change, but the only thing that makes me pause for thought is whether there are toolchains out there which accept __uint128_t but not __int128. Then again, if that crops up as an issue we can probably just tweak the typedef we have in uapi/linux/types.h.

That's all fine to me in concept, so:

Acked-by Mark Rutland <[email protected]>

A few places in arch/arm64/kernel/fpsimd.c and arch/arm64/kernel/ptrace.c use __uint128_t to match the uapi headers. For consistency (and to avoid people accidentally using __uint128_t in future), I reckon it would be good to fix those up to match, but that can be a follow-up.

Mark.

Quoted 64 lines

 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

index 6fed93fb2536..15649a253a57 100644
@@ -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

index e29bf3e2d0cc..d250ca7a1d46 100644
@@ -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.738.g0c8ab3ebcc-goog

Will Deacon

author maintainer Applied

2026-06-23 13:46 UTC #4 lore raw

In reply to Will Deacon

Quoted 9 lines · Will Deacon

The 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.
[...]

Applied to arm64 (for-next/core), thanks!

[1/1] arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers

      https://git.kernel.org/arm64/c/9d6306113f92

Cheers,

Signature · 5 lines

Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev