Skip to contentSkip to conversation

Use __u128 in arm64 UAPI headers

PATCH Applied Will Deacon 2 participants 7 messages Jun 26 – Sep 4

Subsystems (2)
lore
Share & tools
lore

Will Deacon

author maintainer
#0 lore raw

v2 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]

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 __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
author maintainer
#1 lore raw

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

Cc Arnd Bergmann <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>
Cc David Matlack <[email protected]>
---
 tools/include/linux/types.h | 5 +++++
 1 file changed, 5 insertions(+)
tools/include/linux/types.h +5 -0
index d41f8a261bce..b6c473b7920d 100644
@@ -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
#2 lore raw

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 by uapi/linux/types.h, copy that typedef over to the private linux/types.h header used by the tools directory.

Cc Arnd Bergmann <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>
Cc David Matlack <[email protected]>
---
  tools/include/linux/types.h | 5 +++++
  1 file changed, 5 insertions(+)
tools/include/linux/types.h +5 -0
index d41f8a261bce..b6c473b7920d 100644
@@ -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.
author maintainer
#3 lore raw

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

In reply to 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]>
---
 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.799.gd6f94ed593-goog
author maintainer Applied
#4 lore raw
In reply to Will Deacon
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 of linux/types.h used by the tools/ 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
#5 lore raw
In reply to Will Deacon

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 of linux/types.h used by the tools/ 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 __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(-)
author maintainer
#6 lore raw
Quoted 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 of linux/types.h used by the tools/ 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

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