[0/6] updates for linux v5.3

Submitted by Szabolcs Nagy on Nov. 10, 2019, 1:08 a.m.

Details

Message ID 20191110010802.GC25646@port70.net
State New
Series "updates for linux v5.3"
Headers show

Patch hide | download patch | download mbox

From 4a12221eb698f1913a8b2bfd4f91b8b878378aa2 Mon Sep 17 00:00:00 2001
From: Szabolcs Nagy <nsz@port70.net>
Date: Sun, 3 Nov 2019 23:27:31 +0000
Subject: [PATCH 6/6] add clone3 syscall number from linux v5.3

the syscall number is reserved on all targets, but it is not wired up
on all targets, see

  linux commit 8f6ccf6159aed1f04c6d179f61f6fb2691261e84
  Merge tag 'clone3-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux

  linux commit 8f3220a806545442f6f26195bc491520f5276e7c
  arch: wire-up clone3() syscall

  linux commit 7f192e3cd316ba58c88dfa26796cf77789dd9872
  fork: add clone3
---
 arch/aarch64/bits/syscall.h.in    | 1 +
 arch/arm/bits/syscall.h.in        | 1 +
 arch/i386/bits/syscall.h.in       | 1 +
 arch/microblaze/bits/syscall.h.in | 1 +
 arch/or1k/bits/syscall.h.in       | 1 +
 arch/powerpc/bits/syscall.h.in    | 1 +
 arch/powerpc64/bits/syscall.h.in  | 1 +
 arch/riscv64/bits/syscall.h.in    | 1 +
 arch/s390x/bits/syscall.h.in      | 1 +
 arch/x32/bits/syscall.h.in        | 2 ++
 arch/x86_64/bits/syscall.h.in     | 1 +
 11 files changed, 12 insertions(+)

diff --git a/arch/aarch64/bits/syscall.h.in b/arch/aarch64/bits/syscall.h.in
index 2f2c3588..93648afd 100644
--- a/arch/aarch64/bits/syscall.h.in
+++ b/arch/aarch64/bits/syscall.h.in
@@ -288,4 +288,5 @@ 
 #define __NR_fsmount		432
 #define __NR_fspick		433
 #define __NR_pidfd_open		434
+#define __NR_clone3		435
 
diff --git a/arch/arm/bits/syscall.h.in b/arch/arm/bits/syscall.h.in
index 59001fbe..8ab5df1d 100644
--- a/arch/arm/bits/syscall.h.in
+++ b/arch/arm/bits/syscall.h.in
@@ -388,6 +388,7 @@ 
 #define __NR_fsmount		432
 #define __NR_fspick		433
 #define __NR_pidfd_open		434
+#define __NR_clone3		435
 
 #define __ARM_NR_breakpoint	0x0f0001
 #define __ARM_NR_cacheflush	0x0f0002
diff --git a/arch/i386/bits/syscall.h.in b/arch/i386/bits/syscall.h.in
index ef1f9d57..bb841677 100644
--- a/arch/i386/bits/syscall.h.in
+++ b/arch/i386/bits/syscall.h.in
@@ -425,4 +425,5 @@ 
 #define __NR_fsmount		432
 #define __NR_fspick		433
 #define __NR_pidfd_open		434
+#define __NR_clone3		435
 
diff --git a/arch/microblaze/bits/syscall.h.in b/arch/microblaze/bits/syscall.h.in
index ec6f7666..afefb354 100644
--- a/arch/microblaze/bits/syscall.h.in
+++ b/arch/microblaze/bits/syscall.h.in
@@ -426,4 +426,5 @@ 
 #define __NR_fsmount		432
 #define __NR_fspick		433
 #define __NR_pidfd_open		434
+#define __NR_clone3		435
 
diff --git a/arch/or1k/bits/syscall.h.in b/arch/or1k/bits/syscall.h.in
index c863f929..eaa1a935 100644
--- a/arch/or1k/bits/syscall.h.in
+++ b/arch/or1k/bits/syscall.h.in
@@ -310,4 +310,5 @@ 
 #define __NR_fsmount		432
 #define __NR_fspick		433
 #define __NR_pidfd_open		434
+#define __NR_clone3		435
 
diff --git a/arch/powerpc/bits/syscall.h.in b/arch/powerpc/bits/syscall.h.in
index dff8472c..d8b6a247 100644
--- a/arch/powerpc/bits/syscall.h.in
+++ b/arch/powerpc/bits/syscall.h.in
@@ -414,4 +414,5 @@ 
 #define __NR_fsmount		432
 #define __NR_fspick		433
 #define __NR_pidfd_open		434
+#define __NR_clone3		435
 
diff --git a/arch/powerpc64/bits/syscall.h.in b/arch/powerpc64/bits/syscall.h.in
index de65c860..b935864c 100644
--- a/arch/powerpc64/bits/syscall.h.in
+++ b/arch/powerpc64/bits/syscall.h.in
@@ -386,4 +386,5 @@ 
 #define __NR_fsmount		432
 #define __NR_fspick		433
 #define __NR_pidfd_open		434
+#define __NR_clone3		435
 
diff --git a/arch/riscv64/bits/syscall.h.in b/arch/riscv64/bits/syscall.h.in
index c5e99370..0043eeba 100644
--- a/arch/riscv64/bits/syscall.h.in
+++ b/arch/riscv64/bits/syscall.h.in
@@ -288,6 +288,7 @@ 
 #define __NR_fsmount		432
 #define __NR_fspick		433
 #define __NR_pidfd_open		434
+#define __NR_clone3		435
 
 #define __NR_sysriscv __NR_arch_specific_syscall
 #define __NR_riscv_flush_icache (__NR_sysriscv + 15)
diff --git a/arch/s390x/bits/syscall.h.in b/arch/s390x/bits/syscall.h.in
index ef526d79..e89f3782 100644
--- a/arch/s390x/bits/syscall.h.in
+++ b/arch/s390x/bits/syscall.h.in
@@ -351,4 +351,5 @@ 
 #define __NR_fsmount		432
 #define __NR_fspick		433
 #define __NR_pidfd_open		434
+#define __NR_clone3		435
 
diff --git a/arch/x32/bits/syscall.h.in b/arch/x32/bits/syscall.h.in
index 9430d760..f47bdee5 100644
--- a/arch/x32/bits/syscall.h.in
+++ b/arch/x32/bits/syscall.h.in
@@ -297,6 +297,8 @@ 
 #define __NR_fsmount		(0x40000000 + 432)
 #define __NR_fspick		(0x40000000 + 433)
 #define __NR_pidfd_open		(0x40000000 + 434)
+#define __NR_clone3		(0x40000000 + 435)
+
 
 #define __NR_rt_sigaction (0x40000000 + 512)
 #define __NR_rt_sigreturn (0x40000000 + 513)
diff --git a/arch/x86_64/bits/syscall.h.in b/arch/x86_64/bits/syscall.h.in
index fc75d49c..6a646ad3 100644
--- a/arch/x86_64/bits/syscall.h.in
+++ b/arch/x86_64/bits/syscall.h.in
@@ -344,4 +344,5 @@ 
 #define __NR_fsmount		432
 #define __NR_fspick		433
 #define __NR_pidfd_open		434
+#define __NR_clone3		435
 
-- 
2.23.0


Comments

Rich Felker Nov. 10, 2019, 6:14 a.m.
On Sun, Nov 10, 2019 at 02:08:02AM +0100, Szabolcs Nagy wrote:
> >From 560fd1ebe616fd59c0abcaf86bec6109bfcd2141 Mon Sep 17 00:00:00 2001
> From: Szabolcs Nagy <nsz@port70.net>
> Date: Sun, 3 Nov 2019 22:45:05 +0000
> Subject: [PATCH 4/6] sys/ptrace.h: add PTRACE_GET_SYSCALL_INFO from linux v5.3
> 
> ptrace API to get details of the syscall the tracee is blocked in, see
> 
>   linux commit 201766a20e30f982ccfe36bebfad9602c3ff574a
>   ptrace: add PTRACE_GET_SYSCALL_INFO request
> 
> the align attribute was used to keep the layout the same across targets
> e.g. on m68k uint32_t is 2 byte aligned, this helps with compat ptrace.

Can you explain the motivation for this? At first I thought it was for
overall alignment of the structure, but there are also 64-bit members
that aren't aligned, so presumably this is only to get padding after
the initial uint8_t? If so, just add 3 explicit padding members:

> ---
>  include/sys/ptrace.h | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/include/sys/ptrace.h b/include/sys/ptrace.h
> index 229e1f3d..2a868093 100644
> --- a/include/sys/ptrace.h
> +++ b/include/sys/ptrace.h
> @@ -41,6 +41,7 @@ extern "C" {
>  #define PTRACE_SETSIGMASK 0x420b
>  #define PTRACE_SECCOMP_GET_FILTER 0x420c
>  #define PTRACE_SECCOMP_GET_METADATA 0x420d
> +#define PTRACE_GET_SYSCALL_INFO 0x420e
>  
>  #define PT_READ_I PTRACE_PEEKTEXT
>  #define PT_READ_D PTRACE_PEEKDATA
> @@ -88,6 +89,11 @@ extern "C" {
>  
>  #define PTRACE_PEEKSIGINFO_SHARED 1
>  
> +#define PTRACE_SYSCALL_INFO_NONE 0
> +#define PTRACE_SYSCALL_INFO_ENTRY 1
> +#define PTRACE_SYSCALL_INFO_EXIT 2
> +#define PTRACE_SYSCALL_INFO_SECCOMP 3
> +
>  #include <bits/ptrace.h>
>  
>  struct __ptrace_peeksiginfo_args {
> @@ -101,6 +107,28 @@ struct __ptrace_seccomp_metadata {
>  	uint64_t flags;
>  };
>  
> +struct __ptrace_syscall_info {
> +	uint8_t op;

Like uint8_t op, __pad[3];

> +	uint32_t arch __attribute__((__aligned__(4)));
> +	uint64_t instruction_pointer;
> +	uint64_t stack_pointer;
> +	union {
> +		struct {
> +			uint64_t nr;
> +			uint64_t args[6];
> +		} entry;
> +		struct {
> +			int64_t rval;
> +			uint8_t is_error;
> +		} exit;
> +		struct {
> +			uint64_t nr;
> +			uint64_t args[6];
> +			uint32_t ret_data;
> +		} seccomp;
> +	};
> +};
> +
>  long ptrace(int, ...);

Otherwise, the API having reserved-namespace struct names is ugly but
it seems this is nothing new...

Rich
Szabolcs Nagy Nov. 10, 2019, 12:02 p.m.
* Rich Felker <dalias@libc.org> [2019-11-10 01:14:09 -0500]:
> On Sun, Nov 10, 2019 at 02:08:02AM +0100, Szabolcs Nagy wrote:
> > >From 560fd1ebe616fd59c0abcaf86bec6109bfcd2141 Mon Sep 17 00:00:00 2001
> > From: Szabolcs Nagy <nsz@port70.net>
> > Date: Sun, 3 Nov 2019 22:45:05 +0000
> > Subject: [PATCH 4/6] sys/ptrace.h: add PTRACE_GET_SYSCALL_INFO from linux v5.3
> > 
> > ptrace API to get details of the syscall the tracee is blocked in, see
> > 
> >   linux commit 201766a20e30f982ccfe36bebfad9602c3ff574a
> >   ptrace: add PTRACE_GET_SYSCALL_INFO request
> > 
> > the align attribute was used to keep the layout the same across targets
> > e.g. on m68k uint32_t is 2 byte aligned, this helps with compat ptrace.
> 
> Can you explain the motivation for this? At first I thought it was for
> overall alignment of the structure, but there are also 64-bit members
> that aren't aligned, so presumably this is only to get padding after
> the initial uint8_t? If so, just add 3 explicit padding members:

the original linux struct had padding but during
review they changed it to aligned because some
linux devs thought that made the intent clearer
or more future proof (e.g. what if uint64_t is
also 2byte aligned, but on the 64bit version of
the same architecture it's 8byte aligned, then
compat ptrace would not work because one abi
would have padding and the other wouldnt).

i guess for musl either works, but the current
struct is how it is defined in glibc.

> >  struct __ptrace_peeksiginfo_args {
> > @@ -101,6 +107,28 @@ struct __ptrace_seccomp_metadata {
> >  	uint64_t flags;
> >  };
> >  
> > +struct __ptrace_syscall_info {
> > +	uint8_t op;
> 
> Like uint8_t op, __pad[3];
> 
> > +	uint32_t arch __attribute__((__aligned__(4)));
> > +	uint64_t instruction_pointer;
> > +	uint64_t stack_pointer;
> > +	union {
> > +		struct {
> > +			uint64_t nr;
> > +			uint64_t args[6];
> > +		} entry;
> > +		struct {
> > +			int64_t rval;
> > +			uint8_t is_error;
> > +		} exit;
> > +		struct {
> > +			uint64_t nr;
> > +			uint64_t args[6];
> > +			uint32_t ret_data;
> > +		} seccomp;
> > +	};
> > +};
> > +
> >  long ptrace(int, ...);
> 
> Otherwise, the API having reserved-namespace struct names is ugly but
> it seems this is nothing new...

glibc started using this style (i guess not to conflict
with linux uapi, which is often included when ptrace is
used: strace, gdb,..)
Rich Felker Nov. 12, 2019, 3:01 a.m.
On Sun, Nov 10, 2019 at 01:02:53PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2019-11-10 01:14:09 -0500]:
> > On Sun, Nov 10, 2019 at 02:08:02AM +0100, Szabolcs Nagy wrote:
> > > >From 560fd1ebe616fd59c0abcaf86bec6109bfcd2141 Mon Sep 17 00:00:00 2001
> > > From: Szabolcs Nagy <nsz@port70.net>
> > > Date: Sun, 3 Nov 2019 22:45:05 +0000
> > > Subject: [PATCH 4/6] sys/ptrace.h: add PTRACE_GET_SYSCALL_INFO from linux v5.3
> > > 
> > > ptrace API to get details of the syscall the tracee is blocked in, see
> > > 
> > >   linux commit 201766a20e30f982ccfe36bebfad9602c3ff574a
> > >   ptrace: add PTRACE_GET_SYSCALL_INFO request
> > > 
> > > the align attribute was used to keep the layout the same across targets
> > > e.g. on m68k uint32_t is 2 byte aligned, this helps with compat ptrace.
> > 
> > Can you explain the motivation for this? At first I thought it was for
> > overall alignment of the structure, but there are also 64-bit members
> > that aren't aligned, so presumably this is only to get padding after
> > the initial uint8_t? If so, just add 3 explicit padding members:
> 
> the original linux struct had padding but during
> review they changed it to aligned because some
> linux devs thought that made the intent clearer
> or more future proof (e.g. what if uint64_t is
> also 2byte aligned, but on the 64bit version of
> the same architecture it's 8byte aligned, then
> compat ptrace would not work because one abi
> would have padding and the other wouldnt).

I don't follow that line of reasoning; the alignment would potentially
differ, but the layout wouldn't, and that's why I initially suspected
they were doing this for alignment. In any case, the only arch without
at least 4-byte alignment is m68k, and it's not going to have a 64-bit
version.

> i guess for musl either works, but the current
> struct is how it is defined in glibc.

Generally in musl we prefer not using extensions in public headers
except where the effect can be achieved in no other way. Only m68k is
affected by using the forced alignment here, but I don't think there's
any strong reason to prefer one way or the other. I think I'd want to
include the padding even if we do also include
_Alignas/alignas/__attribute__((__aligned__)) (dependent on language
version macros) so that in the fallback case the layout is still
correct even if the alignment isn't (on m68k only).

Rich
Markus Wichmann Nov. 12, 2019, 5:16 a.m.
On Mon, Nov 11, 2019 at 10:01:50PM -0500, Rich Felker wrote:
> I don't follow that line of reasoning; the alignment would potentially
> differ, but the layout wouldn't, and that's why I initially suspected
> they were doing this for alignment. In any case, the only arch without
> at least 4-byte alignment is m68k, and it's not going to have a 64-bit
> version.
>

Does the alignment even matter in this case? Any variable of this type
passed to the kernel must be copied into kernel space, anyway. And
there, the destination can be made to have any alignment the kernel
authors should like to choose. So what does the alignment of the source
matter?

Ciao,
Markus
Szabolcs Nagy Nov. 12, 2019, 11:16 a.m.
* Rich Felker <dalias@libc.org> [2019-11-11 22:01:50 -0500]:

> On Sun, Nov 10, 2019 at 01:02:53PM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2019-11-10 01:14:09 -0500]:
> > > On Sun, Nov 10, 2019 at 02:08:02AM +0100, Szabolcs Nagy wrote:
> > > > >From 560fd1ebe616fd59c0abcaf86bec6109bfcd2141 Mon Sep 17 00:00:00 2001
> > > > From: Szabolcs Nagy <nsz@port70.net>
> > > > Date: Sun, 3 Nov 2019 22:45:05 +0000
> > > > Subject: [PATCH 4/6] sys/ptrace.h: add PTRACE_GET_SYSCALL_INFO from linux v5.3
> > > > 
> > > > ptrace API to get details of the syscall the tracee is blocked in, see
> > > > 
> > > >   linux commit 201766a20e30f982ccfe36bebfad9602c3ff574a
> > > >   ptrace: add PTRACE_GET_SYSCALL_INFO request
> > > > 
> > > > the align attribute was used to keep the layout the same across targets
> > > > e.g. on m68k uint32_t is 2 byte aligned, this helps with compat ptrace.
> > > 
> > > Can you explain the motivation for this? At first I thought it was for
> > > overall alignment of the structure, but there are also 64-bit members
> > > that aren't aligned, so presumably this is only to get padding after
> > > the initial uint8_t? If so, just add 3 explicit padding members:
> > 
> > the original linux struct had padding but during
> > review they changed it to aligned because some
> > linux devs thought that made the intent clearer
> > or more future proof (e.g. what if uint64_t is
> > also 2byte aligned, but on the 64bit version of
> > the same architecture it's 8byte aligned, then
> > compat ptrace would not work because one abi
> > would have padding and the other wouldnt).
> 
> I don't follow that line of reasoning; the alignment would potentially
> differ, but the layout wouldn't, and that's why I initially suspected
> they were doing this for alignment. In any case, the only arch without
> at least 4-byte alignment is m68k, and it's not going to have a 64-bit
> version.

why would the layout be the same?

 uint8_t x;
 uint64_t y; // aligned to 2 bytes

and

 uint8_t x;
 uint64_t y; // aligned to 4 bytes

should have different layout (1 vs 3 bytes padding).

> 
> > i guess for musl either works, but the current
> > struct is how it is defined in glibc.
> 
> Generally in musl we prefer not using extensions in public headers
> except where the effect can be achieved in no other way. Only m68k is
> affected by using the forced alignment here, but I don't think there's
> any strong reason to prefer one way or the other. I think I'd want to
> include the padding even if we do also include
> _Alignas/alignas/__attribute__((__aligned__)) (dependent on language
> version macros) so that in the fallback case the layout is still
> correct even if the alignment isn't (on m68k only).

ok with me.
Rich Felker Nov. 12, 2019, 4:34 p.m.
On Tue, Nov 12, 2019 at 12:16:06PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2019-11-11 22:01:50 -0500]:
> 
> > On Sun, Nov 10, 2019 at 01:02:53PM +0100, Szabolcs Nagy wrote:
> > > * Rich Felker <dalias@libc.org> [2019-11-10 01:14:09 -0500]:
> > > > On Sun, Nov 10, 2019 at 02:08:02AM +0100, Szabolcs Nagy wrote:
> > > > > >From 560fd1ebe616fd59c0abcaf86bec6109bfcd2141 Mon Sep 17 00:00:00 2001
> > > > > From: Szabolcs Nagy <nsz@port70.net>
> > > > > Date: Sun, 3 Nov 2019 22:45:05 +0000
> > > > > Subject: [PATCH 4/6] sys/ptrace.h: add PTRACE_GET_SYSCALL_INFO from linux v5.3
> > > > > 
> > > > > ptrace API to get details of the syscall the tracee is blocked in, see
> > > > > 
> > > > >   linux commit 201766a20e30f982ccfe36bebfad9602c3ff574a
> > > > >   ptrace: add PTRACE_GET_SYSCALL_INFO request
> > > > > 
> > > > > the align attribute was used to keep the layout the same across targets
> > > > > e.g. on m68k uint32_t is 2 byte aligned, this helps with compat ptrace.
> > > > 
> > > > Can you explain the motivation for this? At first I thought it was for
> > > > overall alignment of the structure, but there are also 64-bit members
> > > > that aren't aligned, so presumably this is only to get padding after
> > > > the initial uint8_t? If so, just add 3 explicit padding members:
> > > 
> > > the original linux struct had padding but during
> > > review they changed it to aligned because some
> > > linux devs thought that made the intent clearer
> > > or more future proof (e.g. what if uint64_t is
> > > also 2byte aligned, but on the 64bit version of
> > > the same architecture it's 8byte aligned, then
> > > compat ptrace would not work because one abi
> > > would have padding and the other wouldnt).
> > 
> > I don't follow that line of reasoning; the alignment would potentially
> > differ, but the layout wouldn't, and that's why I initially suspected
> > they were doing this for alignment. In any case, the only arch without
> > at least 4-byte alignment is m68k, and it's not going to have a 64-bit
> > version.
> 
> why would the layout be the same?
> 
>  uint8_t x;
>  uint64_t y; // aligned to 2 bytes
> 
> and
> 
>  uint8_t x;
>  uint64_t y; // aligned to 4 bytes
> 
> should have different layout (1 vs 3 bytes padding).

I'm talking about doing it with explicit padding, and thought that's
what we were comparing against, e.g.:

uint8_t x, __pad[7];
uint64_t y;

> > > i guess for musl either works, but the current
> > > struct is how it is defined in glibc.
> > 
> > Generally in musl we prefer not using extensions in public headers
> > except where the effect can be achieved in no other way. Only m68k is
> > affected by using the forced alignment here, but I don't think there's
> > any strong reason to prefer one way or the other. I think I'd want to
> > include the padding even if we do also include
> > _Alignas/alignas/__attribute__((__aligned__)) (dependent on language
> > version macros) so that in the fallback case the layout is still
> > correct even if the alignment isn't (on m68k only).
> 
> ok with me.

Any preference on which (also having the aligned, or not)? I'd
probably lean towards omitting it but I don't have a strong opinion on
this.

Rich
Szabolcs Nagy Nov. 12, 2019, 5:05 p.m.
* Rich Felker <dalias@libc.org> [2019-11-12 11:34:46 -0500]:
> On Tue, Nov 12, 2019 at 12:16:06PM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2019-11-11 22:01:50 -0500]:
> > > On Sun, Nov 10, 2019 at 01:02:53PM +0100, Szabolcs Nagy wrote:
> > > > * Rich Felker <dalias@libc.org> [2019-11-10 01:14:09 -0500]:
> > > > > On Sun, Nov 10, 2019 at 02:08:02AM +0100, Szabolcs Nagy wrote:
> > > > > > >From 560fd1ebe616fd59c0abcaf86bec6109bfcd2141 Mon Sep 17 00:00:00 2001
> > > > > > From: Szabolcs Nagy <nsz@port70.net>
> > > > > > Date: Sun, 3 Nov 2019 22:45:05 +0000
> > > > > > Subject: [PATCH 4/6] sys/ptrace.h: add PTRACE_GET_SYSCALL_INFO from linux v5.3
> > > > > > 
> > > > > > ptrace API to get details of the syscall the tracee is blocked in, see
> > > > > > 
> > > > > >   linux commit 201766a20e30f982ccfe36bebfad9602c3ff574a
> > > > > >   ptrace: add PTRACE_GET_SYSCALL_INFO request
> > > > > > 
> > > > > > the align attribute was used to keep the layout the same across targets
> > > > > > e.g. on m68k uint32_t is 2 byte aligned, this helps with compat ptrace.
> > > > > 
> > > > > Can you explain the motivation for this? At first I thought it was for
> > > > > overall alignment of the structure, but there are also 64-bit members
> > > > > that aren't aligned, so presumably this is only to get padding after
> > > > > the initial uint8_t? If so, just add 3 explicit padding members:
> > > > 
> > > > the original linux struct had padding but during
> > > > review they changed it to aligned because some
> > > > linux devs thought that made the intent clearer
> > > > or more future proof (e.g. what if uint64_t is
> > > > also 2byte aligned, but on the 64bit version of
> > > > the same architecture it's 8byte aligned, then
> > > > compat ptrace would not work because one abi
> > > > would have padding and the other wouldnt).
> > > 
> > > I don't follow that line of reasoning; the alignment would potentially
> > > differ, but the layout wouldn't, and that's why I initially suspected
> > > they were doing this for alignment. In any case, the only arch without
> > > at least 4-byte alignment is m68k, and it's not going to have a 64-bit
> > > version.
> > 
> > why would the layout be the same?
> > 
> >  uint8_t x;
> >  uint64_t y; // aligned to 2 bytes
> > 
> > and
> > 
> >  uint8_t x;
> >  uint64_t y; // aligned to 4 bytes
> > 
> > should have different layout (1 vs 3 bytes padding).
> 
> I'm talking about doing it with explicit padding, and thought that's
> what we were comparing against, e.g.:
> 
> uint8_t x, __pad[7];
> uint64_t y;

ok
i reread the discussion and now i'm unsure about the reasoning:

v5 discussion:
https://marc.info/?l=linux-api&m=154454540314234&w=2
see v6 changelog:
https://marc.info/?l=linux-api&m=154472189430098&w=2

it seems the reviewer asked for comments for the paddings,
so they were removed to avoid comments?

> Any preference on which (also having the aligned, or not)? I'd
> probably lean towards omitting it but I don't have a strong opinion on
> this.

yes, it can be omitted i think if everything uses
libc headers consistently.

(e.g. if something uses the kernel headers in one
tu then it won't be compatible with another tu that
uses libc types)