mailing list of musl libc
 help / color / mirror / code / Atom feed
* [PATCH 0/6] updates for linux v5.3
@ 2019-11-10  1:08 Szabolcs Nagy
  2019-11-10  6:14 ` Rich Felker
  0 siblings, 1 reply; 9+ messages in thread
From: Szabolcs Nagy @ 2019-11-10  1:08 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

attached the patches.

Szabolcs Nagy (6):
  netinet/tcp.h: add TCP_TX_DELAY from linux v5.3
  netinet/if_ether.h: add ETH_P_LLDP from linux v5.3
  sys/socket.h: add SO_DETACH_REUSEPORT_BPF from linux v5.3
  sys/ptrace.h: add PTRACE_GET_SYSCALL_INFO from linux v5.3
  add pidfd_open syscall number from linux v5.3
  add clone3 syscall number from linux v5.3

 arch/aarch64/bits/syscall.h.in    |  2 ++
 arch/arm/bits/syscall.h.in        |  2 ++
 arch/i386/bits/syscall.h.in       |  2 ++
 arch/m68k/bits/syscall.h.in       |  1 +
 arch/microblaze/bits/syscall.h.in |  2 ++
 arch/mips/bits/syscall.h.in       |  1 +
 arch/mips64/bits/syscall.h.in     |  1 +
 arch/mipsn32/bits/syscall.h.in    |  1 +
 arch/or1k/bits/syscall.h.in       |  2 ++
 arch/powerpc/bits/syscall.h.in    |  2 ++
 arch/powerpc64/bits/syscall.h.in  |  2 ++
 arch/riscv64/bits/syscall.h.in    |  2 ++
 arch/s390x/bits/syscall.h.in      |  2 ++
 arch/sh/bits/syscall.h.in         |  1 +
 arch/x32/bits/syscall.h.in        |  3 +++
 arch/x86_64/bits/syscall.h.in     |  2 ++
 include/netinet/if_ether.h        |  1 +
 include/netinet/tcp.h             |  1 +
 include/sys/ptrace.h              | 28 ++++++++++++++++++++++++++++
 include/sys/socket.h              |  1 +
 20 files changed, 59 insertions(+)

-- 
2.23.0


[-- Attachment #2: 0001-netinet-tcp.h-add-TCP_TX_DELAY-from-linux-v5.3.patch --]
[-- Type: text/x-diff, Size: 726 bytes --]

From fb6bc56c9f894857c95c1231bcfa3ba612798889 Mon Sep 17 00:00:00 2001
From: Szabolcs Nagy <nsz@port70.net>
Date: Thu, 31 Oct 2019 21:15:43 +0000
Subject: [PATCH 1/6] netinet/tcp.h: add TCP_TX_DELAY from linux v5.3

see

  linux commit a842fe1425cb20f457abd3f8ef98b468f83ca98b
  tcp: add optional per socket transmit delay
---
 include/netinet/tcp.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/netinet/tcp.h b/include/netinet/tcp.h
index adcd45e7..69de9d5a 100644
--- a/include/netinet/tcp.h
+++ b/include/netinet/tcp.h
@@ -38,6 +38,7 @@
 #define TCP_FASTOPEN_NO_COOKIE 34
 #define TCP_ZEROCOPY_RECEIVE   35
 #define TCP_INQ          36
+#define TCP_TX_DELAY     37
 
 #define TCP_CM_INQ TCP_INQ
 
-- 
2.23.0


[-- Attachment #3: 0002-netinet-if_ether.h-add-ETH_P_LLDP-from-linux-v5.3.patch --]
[-- Type: text/x-diff, Size: 784 bytes --]

From 640fa13e212911b83c21eedbda67177d8309a02e Mon Sep 17 00:00:00 2001
From: Szabolcs Nagy <nsz@port70.net>
Date: Sun, 3 Nov 2019 22:22:32 +0000
Subject: [PATCH 2/6] netinet/if_ether.h: add ETH_P_LLDP from linux v5.3

see

  linux commit c54c2c72b2b90a3ba61b8cad032a578ce2bf5b35
  net: Add a define for LLDP ethertype
---
 include/netinet/if_ether.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/netinet/if_ether.h b/include/netinet/if_ether.h
index 8af47dbe..a08485e7 100644
--- a/include/netinet/if_ether.h
+++ b/include/netinet/if_ether.h
@@ -58,6 +58,7 @@
 #define ETH_P_ERSPAN	0x88BE
 #define ETH_P_PREAUTH	0x88C7
 #define ETH_P_TIPC	0x88CA
+#define ETH_P_LLDP	0x88CC
 #define ETH_P_MACSEC	0x88E5
 #define ETH_P_8021AH	0x88E7
 #define ETH_P_MVRP	0x88F5
-- 
2.23.0


[-- Attachment #4: 0003-sys-socket.h-add-SO_DETACH_REUSEPORT_BPF-from-linux-.patch --]
[-- Type: text/x-diff, Size: 782 bytes --]

From 6f406dde72386bf79dae6736cc10215896bad7a6 Mon Sep 17 00:00:00 2001
From: Szabolcs Nagy <nsz@port70.net>
Date: Sun, 3 Nov 2019 22:27:13 +0000
Subject: [PATCH 3/6] sys/socket.h: add SO_DETACH_REUSEPORT_BPF from linux v5.3

see

  linux commit 99f3a064bc2e4bd5fe50218646c5be342f2ad18c
  bpf: net: Add SO_DETACH_REUSEPORT_BPF
---
 include/sys/socket.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/sys/socket.h b/include/sys/socket.h
index a1c0b01c..38f5bb17 100644
--- a/include/sys/socket.h
+++ b/include/sys/socket.h
@@ -288,6 +288,7 @@ struct linger {
 #define SO_TXTIME               61
 #define SCM_TXTIME              SO_TXTIME
 #define SO_BINDTOIFINDEX        62
+#define SO_DETACH_REUSEPORT_BPF 68
 
 #ifndef SOL_SOCKET
 #define SOL_SOCKET      1
-- 
2.23.0


[-- Attachment #5: 0004-sys-ptrace.h-add-PTRACE_GET_SYSCALL_INFO-from-linux-.patch --]
[-- Type: text/x-diff, Size: 1858 bytes --]

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.
---
 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;
+	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, ...);
 
 #ifdef __cplusplus
-- 
2.23.0


[-- Attachment #6: 0005-add-pidfd_open-syscall-number-from-linux-v5.3.patch --]
[-- Type: text/x-diff, Size: 6395 bytes --]

From b6ad04e84cd72f2f59cbeb1fce8f5119570d043a Mon Sep 17 00:00:00 2001
From: Szabolcs Nagy <nsz@port70.net>
Date: Sun, 3 Nov 2019 23:16:53 +0000
Subject: [PATCH 5/6] add pidfd_open syscall number from linux v5.3

see

  linux commit 7615d9e1780e26e0178c93c55b73309a5dc093d7
  arch: wire-up pidfd_open()

  linux commit 32fcb426ec001cb6d5a4a195091a8486ea77e2df
  pid: add pidfd_open()
---
 arch/aarch64/bits/syscall.h.in    | 1 +
 arch/arm/bits/syscall.h.in        | 1 +
 arch/i386/bits/syscall.h.in       | 1 +
 arch/m68k/bits/syscall.h.in       | 1 +
 arch/microblaze/bits/syscall.h.in | 1 +
 arch/mips/bits/syscall.h.in       | 1 +
 arch/mips64/bits/syscall.h.in     | 1 +
 arch/mipsn32/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/sh/bits/syscall.h.in         | 1 +
 arch/x32/bits/syscall.h.in        | 1 +
 arch/x86_64/bits/syscall.h.in     | 1 +
 16 files changed, 16 insertions(+)

diff --git a/arch/aarch64/bits/syscall.h.in b/arch/aarch64/bits/syscall.h.in
index 955e2cab..2f2c3588 100644
--- a/arch/aarch64/bits/syscall.h.in
+++ b/arch/aarch64/bits/syscall.h.in
@@ -287,4 +287,5 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
diff --git a/arch/arm/bits/syscall.h.in b/arch/arm/bits/syscall.h.in
index a565a4ee..59001fbe 100644
--- a/arch/arm/bits/syscall.h.in
+++ b/arch/arm/bits/syscall.h.in
@@ -387,6 +387,7 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
 #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 c95e108e..ef1f9d57 100644
--- a/arch/i386/bits/syscall.h.in
+++ b/arch/i386/bits/syscall.h.in
@@ -424,4 +424,5 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
diff --git a/arch/m68k/bits/syscall.h.in b/arch/m68k/bits/syscall.h.in
index fb522b48..e7f71a5d 100644
--- a/arch/m68k/bits/syscall.h.in
+++ b/arch/m68k/bits/syscall.h.in
@@ -404,3 +404,4 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
diff --git a/arch/microblaze/bits/syscall.h.in b/arch/microblaze/bits/syscall.h.in
index 59f86236..ec6f7666 100644
--- a/arch/microblaze/bits/syscall.h.in
+++ b/arch/microblaze/bits/syscall.h.in
@@ -425,4 +425,5 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
diff --git a/arch/mips/bits/syscall.h.in b/arch/mips/bits/syscall.h.in
index 582fa3b5..7f6f5a4d 100644
--- a/arch/mips/bits/syscall.h.in
+++ b/arch/mips/bits/syscall.h.in
@@ -406,4 +406,5 @@
 #define __NR_fsconfig		4431
 #define __NR_fsmount		4432
 #define __NR_fspick		4433
+#define __NR_pidfd_open		4434
 
diff --git a/arch/mips64/bits/syscall.h.in b/arch/mips64/bits/syscall.h.in
index 34b9752e..1a1ba7c8 100644
--- a/arch/mips64/bits/syscall.h.in
+++ b/arch/mips64/bits/syscall.h.in
@@ -336,4 +336,5 @@
 #define __NR_fsconfig		5431
 #define __NR_fsmount		5432
 #define __NR_fspick		5433
+#define __NR_pidfd_open		5434
 
diff --git a/arch/mipsn32/bits/syscall.h.in b/arch/mipsn32/bits/syscall.h.in
index d80cafa8..fcd5cbf7 100644
--- a/arch/mipsn32/bits/syscall.h.in
+++ b/arch/mipsn32/bits/syscall.h.in
@@ -360,4 +360,5 @@
 #define __NR_fsconfig		6431
 #define __NR_fsmount		6432
 #define __NR_fspick		6433
+#define __NR_pidfd_open		6434
 
diff --git a/arch/or1k/bits/syscall.h.in b/arch/or1k/bits/syscall.h.in
index 8ffcfae8..c863f929 100644
--- a/arch/or1k/bits/syscall.h.in
+++ b/arch/or1k/bits/syscall.h.in
@@ -309,4 +309,5 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
diff --git a/arch/powerpc/bits/syscall.h.in b/arch/powerpc/bits/syscall.h.in
index adcf63db..dff8472c 100644
--- a/arch/powerpc/bits/syscall.h.in
+++ b/arch/powerpc/bits/syscall.h.in
@@ -413,4 +413,5 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
diff --git a/arch/powerpc64/bits/syscall.h.in b/arch/powerpc64/bits/syscall.h.in
index 32545b39..de65c860 100644
--- a/arch/powerpc64/bits/syscall.h.in
+++ b/arch/powerpc64/bits/syscall.h.in
@@ -385,4 +385,5 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
diff --git a/arch/riscv64/bits/syscall.h.in b/arch/riscv64/bits/syscall.h.in
index 1db70cfb..c5e99370 100644
--- a/arch/riscv64/bits/syscall.h.in
+++ b/arch/riscv64/bits/syscall.h.in
@@ -287,6 +287,7 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
 #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 c4c70474..ef526d79 100644
--- a/arch/s390x/bits/syscall.h.in
+++ b/arch/s390x/bits/syscall.h.in
@@ -350,4 +350,5 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
diff --git a/arch/sh/bits/syscall.h.in b/arch/sh/bits/syscall.h.in
index 4705ef93..4e9ae2e0 100644
--- a/arch/sh/bits/syscall.h.in
+++ b/arch/sh/bits/syscall.h.in
@@ -397,4 +397,5 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
diff --git a/arch/x32/bits/syscall.h.in b/arch/x32/bits/syscall.h.in
index 4d72852e..9430d760 100644
--- a/arch/x32/bits/syscall.h.in
+++ b/arch/x32/bits/syscall.h.in
@@ -296,6 +296,7 @@
 #define __NR_fsconfig		(0x40000000 + 431)
 #define __NR_fsmount		(0x40000000 + 432)
 #define __NR_fspick		(0x40000000 + 433)
+#define __NR_pidfd_open		(0x40000000 + 434)
 
 #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 2d4634f6..fc75d49c 100644
--- a/arch/x86_64/bits/syscall.h.in
+++ b/arch/x86_64/bits/syscall.h.in
@@ -343,4 +343,5 @@
 #define __NR_fsconfig		431
 #define __NR_fsmount		432
 #define __NR_fspick		433
+#define __NR_pidfd_open		434
 
-- 
2.23.0


[-- Attachment #7: 0006-add-clone3-syscall-number-from-linux-v5.3.patch --]
[-- Type: text/x-diff, Size: 4856 bytes --]

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/6] updates for linux v5.3
  2019-11-10  1:08 [PATCH 0/6] updates for linux v5.3 Szabolcs Nagy
@ 2019-11-10  6:14 ` Rich Felker
  2019-11-10 12:02   ` Szabolcs Nagy
  0 siblings, 1 reply; 9+ messages in thread
From: Rich Felker @ 2019-11-10  6:14 UTC (permalink / raw)
  To: musl

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/6] updates for linux v5.3
  2019-11-10  6:14 ` Rich Felker
@ 2019-11-10 12:02   ` Szabolcs Nagy
  2019-11-12  3:01     ` Rich Felker
  0 siblings, 1 reply; 9+ messages in thread
From: Szabolcs Nagy @ 2019-11-10 12:02 UTC (permalink / raw)
  To: musl

* 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,..)


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/6] updates for linux v5.3
  2019-11-10 12:02   ` Szabolcs Nagy
@ 2019-11-12  3:01     ` Rich Felker
  2019-11-12  5:16       ` Markus Wichmann
  2019-11-12 11:16       ` Szabolcs Nagy
  0 siblings, 2 replies; 9+ messages in thread
From: Rich Felker @ 2019-11-12  3:01 UTC (permalink / raw)
  To: musl

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/6] updates for linux v5.3
  2019-11-12  3:01     ` Rich Felker
@ 2019-11-12  5:16       ` Markus Wichmann
  2019-11-12 11:16       ` Szabolcs Nagy
  1 sibling, 0 replies; 9+ messages in thread
From: Markus Wichmann @ 2019-11-12  5:16 UTC (permalink / raw)
  To: musl

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/6] updates for linux v5.3
  2019-11-12  3:01     ` Rich Felker
  2019-11-12  5:16       ` Markus Wichmann
@ 2019-11-12 11:16       ` Szabolcs Nagy
  2019-11-12 16:34         ` Rich Felker
  1 sibling, 1 reply; 9+ messages in thread
From: Szabolcs Nagy @ 2019-11-12 11:16 UTC (permalink / raw)
  To: musl

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/6] updates for linux v5.3
  2019-11-12 11:16       ` Szabolcs Nagy
@ 2019-11-12 16:34         ` Rich Felker
  2019-11-12 17:05           ` Szabolcs Nagy
  2019-11-13  0:06           ` Szabolcs Nagy
  0 siblings, 2 replies; 9+ messages in thread
From: Rich Felker @ 2019-11-12 16:34 UTC (permalink / raw)
  To: musl

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/6] updates for linux v5.3
  2019-11-12 16:34         ` Rich Felker
@ 2019-11-12 17:05           ` Szabolcs Nagy
  2019-11-13  0:06           ` Szabolcs Nagy
  1 sibling, 0 replies; 9+ messages in thread
From: Szabolcs Nagy @ 2019-11-12 17:05 UTC (permalink / raw)
  To: musl

* 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)



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/6] updates for linux v5.3
  2019-11-12 16:34         ` Rich Felker
  2019-11-12 17:05           ` Szabolcs Nagy
@ 2019-11-13  0:06           ` Szabolcs Nagy
  1 sibling, 0 replies; 9+ messages in thread
From: Szabolcs Nagy @ 2019-11-13  0:06 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 18 bytes --]

v2 with padding.


[-- Attachment #2: 0004-sys-ptrace.h-add-PTRACE_GET_SYSCALL_INFO-from-linux-.patch --]
[-- Type: text/x-diff, Size: 2054 bytes --]

From 846dd904a3f8b120794bcf1972c8ccbcf3def12f 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

compared to the linux uapi (and glibc) a padding is used instead of
aligned attribute for keeping the layout the same across targets, this
means the alignment of the struct may be different on some targets
(e.g. m68k where uint64_t is 2 byte aligned) but that should not affect
syscalls and this way the abi does not depend on nonstandard extensions.
---
 include/sys/ptrace.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/include/sys/ptrace.h b/include/sys/ptrace.h
index 229e1f3d..5d62a985 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,29 @@ struct __ptrace_seccomp_metadata {
 	uint64_t flags;
 };
 
+struct __ptrace_syscall_info {
+	uint8_t op;
+	uint8_t __pad[3];
+	uint32_t arch;
+	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, ...);
 
 #ifdef __cplusplus
-- 
2.23.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-11-13  0:06 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-10  1:08 [PATCH 0/6] updates for linux v5.3 Szabolcs Nagy
2019-11-10  6:14 ` Rich Felker
2019-11-10 12:02   ` Szabolcs Nagy
2019-11-12  3:01     ` Rich Felker
2019-11-12  5:16       ` Markus Wichmann
2019-11-12 11:16       ` Szabolcs Nagy
2019-11-12 16:34         ` Rich Felker
2019-11-12 17:05           ` Szabolcs Nagy
2019-11-13  0:06           ` Szabolcs Nagy

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).