All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-18 19:31 Russell King
  2016-10-19 15:30 ` Arnd Bergmann
  0 siblings, 1 reply; 49+ messages in thread
From: Russell King @ 2016-10-18 19:31 UTC (permalink / raw)
  To: linux-arm-kernel

Convert ARM to use a similar mechanism to x86 to generate the unistd.h
system call numbers and the various kernel system call tables.  This
means that rather than having to edit three places (asm/unistd.h for
the total number of system calls, uapi/asm/unistd.h for the system call
numbers, and arch/arm/kernel/calls.S for the call table) we have only
one place to edit, making the process much more simple.

The scripts have knowledge of the table padding requirements, so there's
no need to worry about __NR_syscalls not fitting within the immediate
constant field of ALU instructions anymore.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 arch/arm/Makefile                  |   3 +
 arch/arm/include/asm/Kbuild        |   1 +
 arch/arm/include/asm/unistd.h      |  26 ++-
 arch/arm/include/uapi/asm/Kbuild   |   3 +
 arch/arm/include/uapi/asm/unistd.h | 421 +-----------------------------------
 arch/arm/kernel/calls.S            | 412 -----------------------------------
 arch/arm/kernel/entry-common.S     |  76 ++++---
 arch/arm/tools/Makefile            |  62 +++++-
 arch/arm/tools/syscall.tbl         | 428 +++++++++++++++++++++++++++++++++++++
 arch/arm/tools/syscallhdr.sh       |  30 +++
 arch/arm/tools/syscallnr.sh        |  33 +++
 arch/arm/tools/syscalltbl.sh       |  21 ++
 12 files changed, 643 insertions(+), 873 deletions(-)
 delete mode 100644 arch/arm/kernel/calls.S
 create mode 100644 arch/arm/tools/syscall.tbl
 create mode 100644 arch/arm/tools/syscallhdr.sh
 create mode 100644 arch/arm/tools/syscallnr.sh
 create mode 100644 arch/arm/tools/syscalltbl.sh

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 2208a73ba1d4..5a26576fba9a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -311,6 +311,9 @@ all:	$(KBUILD_IMAGE) $(KBUILD_DTBS)
 
 boot := arch/arm/boot
 
+archheaders:
+	$(Q)$(MAKE) $(build)=arch/arm/tools uapi
+
 archprepare:
 	$(Q)$(MAKE) $(build)=arch/arm/tools kapi
 
diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index 5b06064946ce..b7960e3956b2 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -41,3 +41,4 @@ generic-y += trace_clock.h
 generic-y += unaligned.h
 
 generated-y += mach-types.h
+generated-y += unistd-nr.h
diff --git a/arch/arm/include/asm/unistd.h b/arch/arm/include/asm/unistd.h
index 194b69923389..076090d2dbf5 100644
--- a/arch/arm/include/asm/unistd.h
+++ b/arch/arm/include/asm/unistd.h
@@ -14,12 +14,7 @@
 #define __ASM_ARM_UNISTD_H
 
 #include <uapi/asm/unistd.h>
-
-/*
- * This may need to be greater than __NR_last_syscall+1 in order to
- * account for the padding in the syscall table
- */
-#define __NR_syscalls  (396)
+#include <asm/unistd-nr.h>
 
 #define __ARCH_WANT_STAT64
 #define __ARCH_WANT_SYS_GETHOSTNAME
@@ -52,4 +47,23 @@
 #define __IGNORE_fadvise64_64
 #define __IGNORE_migrate_pages
 
+#ifdef __ARM_EABI__
+/*
+ * The following syscalls are obsolete and no longer available for EABI:
+ *  __NR_time
+ *  __NR_umount
+ *  __NR_stime
+ *  __NR_alarm
+ *  __NR_utime
+ *  __NR_getrlimit
+ *  __NR_select
+ *  __NR_readdir
+ *  __NR_mmap
+ *  __NR_socketcall
+ *  __NR_syscall
+ *  __NR_ipc
+ */
+#define __IGNORE_getrlimit
+#endif
+
 #endif /* __ASM_ARM_UNISTD_H */
diff --git a/arch/arm/include/uapi/asm/Kbuild b/arch/arm/include/uapi/asm/Kbuild
index a1c05f93d920..46a76cd6acb6 100644
--- a/arch/arm/include/uapi/asm/Kbuild
+++ b/arch/arm/include/uapi/asm/Kbuild
@@ -18,3 +18,6 @@ header-y += stat.h
 header-y += statfs.h
 header-y += swab.h
 header-y += unistd.h
+genhdr-y += unistd-common.h
+genhdr-y += unistd-oabi.h
+genhdr-y += unistd-eabi.h
diff --git a/arch/arm/include/uapi/asm/unistd.h b/arch/arm/include/uapi/asm/unistd.h
index 2cb9dc770e1d..28bd456494a3 100644
--- a/arch/arm/include/uapi/asm/unistd.h
+++ b/arch/arm/include/uapi/asm/unistd.h
@@ -17,409 +17,14 @@
 
 #if defined(__thumb__) || defined(__ARM_EABI__)
 #define __NR_SYSCALL_BASE	0
+#include <asm/unistd-eabi.h>
 #else
 #define __NR_SYSCALL_BASE	__NR_OABI_SYSCALL_BASE
+#include <asm/unistd-oabi.h>
 #endif
 
-/*
- * This file contains the system call numbers.
- */
-
-#define __NR_restart_syscall		(__NR_SYSCALL_BASE+  0)
-#define __NR_exit			(__NR_SYSCALL_BASE+  1)
-#define __NR_fork			(__NR_SYSCALL_BASE+  2)
-#define __NR_read			(__NR_SYSCALL_BASE+  3)
-#define __NR_write			(__NR_SYSCALL_BASE+  4)
-#define __NR_open			(__NR_SYSCALL_BASE+  5)
-#define __NR_close			(__NR_SYSCALL_BASE+  6)
-					/* 7 was sys_waitpid */
-#define __NR_creat			(__NR_SYSCALL_BASE+  8)
-#define __NR_link			(__NR_SYSCALL_BASE+  9)
-#define __NR_unlink			(__NR_SYSCALL_BASE+ 10)
-#define __NR_execve			(__NR_SYSCALL_BASE+ 11)
-#define __NR_chdir			(__NR_SYSCALL_BASE+ 12)
-#define __NR_time			(__NR_SYSCALL_BASE+ 13)
-#define __NR_mknod			(__NR_SYSCALL_BASE+ 14)
-#define __NR_chmod			(__NR_SYSCALL_BASE+ 15)
-#define __NR_lchown			(__NR_SYSCALL_BASE+ 16)
-					/* 17 was sys_break */
-					/* 18 was sys_stat */
-#define __NR_lseek			(__NR_SYSCALL_BASE+ 19)
-#define __NR_getpid			(__NR_SYSCALL_BASE+ 20)
-#define __NR_mount			(__NR_SYSCALL_BASE+ 21)
-#define __NR_umount			(__NR_SYSCALL_BASE+ 22)
-#define __NR_setuid			(__NR_SYSCALL_BASE+ 23)
-#define __NR_getuid			(__NR_SYSCALL_BASE+ 24)
-#define __NR_stime			(__NR_SYSCALL_BASE+ 25)
-#define __NR_ptrace			(__NR_SYSCALL_BASE+ 26)
-#define __NR_alarm			(__NR_SYSCALL_BASE+ 27)
-					/* 28 was sys_fstat */
-#define __NR_pause			(__NR_SYSCALL_BASE+ 29)
-#define __NR_utime			(__NR_SYSCALL_BASE+ 30)
-					/* 31 was sys_stty */
-					/* 32 was sys_gtty */
-#define __NR_access			(__NR_SYSCALL_BASE+ 33)
-#define __NR_nice			(__NR_SYSCALL_BASE+ 34)
-					/* 35 was sys_ftime */
-#define __NR_sync			(__NR_SYSCALL_BASE+ 36)
-#define __NR_kill			(__NR_SYSCALL_BASE+ 37)
-#define __NR_rename			(__NR_SYSCALL_BASE+ 38)
-#define __NR_mkdir			(__NR_SYSCALL_BASE+ 39)
-#define __NR_rmdir			(__NR_SYSCALL_BASE+ 40)
-#define __NR_dup			(__NR_SYSCALL_BASE+ 41)
-#define __NR_pipe			(__NR_SYSCALL_BASE+ 42)
-#define __NR_times			(__NR_SYSCALL_BASE+ 43)
-					/* 44 was sys_prof */
-#define __NR_brk			(__NR_SYSCALL_BASE+ 45)
-#define __NR_setgid			(__NR_SYSCALL_BASE+ 46)
-#define __NR_getgid			(__NR_SYSCALL_BASE+ 47)
-					/* 48 was sys_signal */
-#define __NR_geteuid			(__NR_SYSCALL_BASE+ 49)
-#define __NR_getegid			(__NR_SYSCALL_BASE+ 50)
-#define __NR_acct			(__NR_SYSCALL_BASE+ 51)
-#define __NR_umount2			(__NR_SYSCALL_BASE+ 52)
-					/* 53 was sys_lock */
-#define __NR_ioctl			(__NR_SYSCALL_BASE+ 54)
-#define __NR_fcntl			(__NR_SYSCALL_BASE+ 55)
-					/* 56 was sys_mpx */
-#define __NR_setpgid			(__NR_SYSCALL_BASE+ 57)
-					/* 58 was sys_ulimit */
-					/* 59 was sys_olduname */
-#define __NR_umask			(__NR_SYSCALL_BASE+ 60)
-#define __NR_chroot			(__NR_SYSCALL_BASE+ 61)
-#define __NR_ustat			(__NR_SYSCALL_BASE+ 62)
-#define __NR_dup2			(__NR_SYSCALL_BASE+ 63)
-#define __NR_getppid			(__NR_SYSCALL_BASE+ 64)
-#define __NR_getpgrp			(__NR_SYSCALL_BASE+ 65)
-#define __NR_setsid			(__NR_SYSCALL_BASE+ 66)
-#define __NR_sigaction			(__NR_SYSCALL_BASE+ 67)
-					/* 68 was sys_sgetmask */
-					/* 69 was sys_ssetmask */
-#define __NR_setreuid			(__NR_SYSCALL_BASE+ 70)
-#define __NR_setregid			(__NR_SYSCALL_BASE+ 71)
-#define __NR_sigsuspend			(__NR_SYSCALL_BASE+ 72)
-#define __NR_sigpending			(__NR_SYSCALL_BASE+ 73)
-#define __NR_sethostname		(__NR_SYSCALL_BASE+ 74)
-#define __NR_setrlimit			(__NR_SYSCALL_BASE+ 75)
-#define __NR_getrlimit			(__NR_SYSCALL_BASE+ 76)	/* Back compat 2GB limited rlimit */
-#define __NR_getrusage			(__NR_SYSCALL_BASE+ 77)
-#define __NR_gettimeofday		(__NR_SYSCALL_BASE+ 78)
-#define __NR_settimeofday		(__NR_SYSCALL_BASE+ 79)
-#define __NR_getgroups			(__NR_SYSCALL_BASE+ 80)
-#define __NR_setgroups			(__NR_SYSCALL_BASE+ 81)
-#define __NR_select			(__NR_SYSCALL_BASE+ 82)
-#define __NR_symlink			(__NR_SYSCALL_BASE+ 83)
-					/* 84 was sys_lstat */
-#define __NR_readlink			(__NR_SYSCALL_BASE+ 85)
-#define __NR_uselib			(__NR_SYSCALL_BASE+ 86)
-#define __NR_swapon			(__NR_SYSCALL_BASE+ 87)
-#define __NR_reboot			(__NR_SYSCALL_BASE+ 88)
-#define __NR_readdir			(__NR_SYSCALL_BASE+ 89)
-#define __NR_mmap			(__NR_SYSCALL_BASE+ 90)
-#define __NR_munmap			(__NR_SYSCALL_BASE+ 91)
-#define __NR_truncate			(__NR_SYSCALL_BASE+ 92)
-#define __NR_ftruncate			(__NR_SYSCALL_BASE+ 93)
-#define __NR_fchmod			(__NR_SYSCALL_BASE+ 94)
-#define __NR_fchown			(__NR_SYSCALL_BASE+ 95)
-#define __NR_getpriority		(__NR_SYSCALL_BASE+ 96)
-#define __NR_setpriority		(__NR_SYSCALL_BASE+ 97)
-					/* 98 was sys_profil */
-#define __NR_statfs			(__NR_SYSCALL_BASE+ 99)
-#define __NR_fstatfs			(__NR_SYSCALL_BASE+100)
-					/* 101 was sys_ioperm */
-#define __NR_socketcall			(__NR_SYSCALL_BASE+102)
-#define __NR_syslog			(__NR_SYSCALL_BASE+103)
-#define __NR_setitimer			(__NR_SYSCALL_BASE+104)
-#define __NR_getitimer			(__NR_SYSCALL_BASE+105)
-#define __NR_stat			(__NR_SYSCALL_BASE+106)
-#define __NR_lstat			(__NR_SYSCALL_BASE+107)
-#define __NR_fstat			(__NR_SYSCALL_BASE+108)
-					/* 109 was sys_uname */
-					/* 110 was sys_iopl */
-#define __NR_vhangup			(__NR_SYSCALL_BASE+111)
-					/* 112 was sys_idle */
-#define __NR_syscall			(__NR_SYSCALL_BASE+113) /* syscall to call a syscall! */
-#define __NR_wait4			(__NR_SYSCALL_BASE+114)
-#define __NR_swapoff			(__NR_SYSCALL_BASE+115)
-#define __NR_sysinfo			(__NR_SYSCALL_BASE+116)
-#define __NR_ipc			(__NR_SYSCALL_BASE+117)
-#define __NR_fsync			(__NR_SYSCALL_BASE+118)
-#define __NR_sigreturn			(__NR_SYSCALL_BASE+119)
-#define __NR_clone			(__NR_SYSCALL_BASE+120)
-#define __NR_setdomainname		(__NR_SYSCALL_BASE+121)
-#define __NR_uname			(__NR_SYSCALL_BASE+122)
-					/* 123 was sys_modify_ldt */
-#define __NR_adjtimex			(__NR_SYSCALL_BASE+124)
-#define __NR_mprotect			(__NR_SYSCALL_BASE+125)
-#define __NR_sigprocmask		(__NR_SYSCALL_BASE+126)
-					/* 127 was sys_create_module */
-#define __NR_init_module		(__NR_SYSCALL_BASE+128)
-#define __NR_delete_module		(__NR_SYSCALL_BASE+129)
-					/* 130 was sys_get_kernel_syms */
-#define __NR_quotactl			(__NR_SYSCALL_BASE+131)
-#define __NR_getpgid			(__NR_SYSCALL_BASE+132)
-#define __NR_fchdir			(__NR_SYSCALL_BASE+133)
-#define __NR_bdflush			(__NR_SYSCALL_BASE+134)
-#define __NR_sysfs			(__NR_SYSCALL_BASE+135)
-#define __NR_personality		(__NR_SYSCALL_BASE+136)
-					/* 137 was sys_afs_syscall */
-#define __NR_setfsuid			(__NR_SYSCALL_BASE+138)
-#define __NR_setfsgid			(__NR_SYSCALL_BASE+139)
-#define __NR__llseek			(__NR_SYSCALL_BASE+140)
-#define __NR_getdents			(__NR_SYSCALL_BASE+141)
-#define __NR__newselect			(__NR_SYSCALL_BASE+142)
-#define __NR_flock			(__NR_SYSCALL_BASE+143)
-#define __NR_msync			(__NR_SYSCALL_BASE+144)
-#define __NR_readv			(__NR_SYSCALL_BASE+145)
-#define __NR_writev			(__NR_SYSCALL_BASE+146)
-#define __NR_getsid			(__NR_SYSCALL_BASE+147)
-#define __NR_fdatasync			(__NR_SYSCALL_BASE+148)
-#define __NR__sysctl			(__NR_SYSCALL_BASE+149)
-#define __NR_mlock			(__NR_SYSCALL_BASE+150)
-#define __NR_munlock			(__NR_SYSCALL_BASE+151)
-#define __NR_mlockall			(__NR_SYSCALL_BASE+152)
-#define __NR_munlockall			(__NR_SYSCALL_BASE+153)
-#define __NR_sched_setparam		(__NR_SYSCALL_BASE+154)
-#define __NR_sched_getparam		(__NR_SYSCALL_BASE+155)
-#define __NR_sched_setscheduler		(__NR_SYSCALL_BASE+156)
-#define __NR_sched_getscheduler		(__NR_SYSCALL_BASE+157)
-#define __NR_sched_yield		(__NR_SYSCALL_BASE+158)
-#define __NR_sched_get_priority_max	(__NR_SYSCALL_BASE+159)
-#define __NR_sched_get_priority_min	(__NR_SYSCALL_BASE+160)
-#define __NR_sched_rr_get_interval	(__NR_SYSCALL_BASE+161)
-#define __NR_nanosleep			(__NR_SYSCALL_BASE+162)
-#define __NR_mremap			(__NR_SYSCALL_BASE+163)
-#define __NR_setresuid			(__NR_SYSCALL_BASE+164)
-#define __NR_getresuid			(__NR_SYSCALL_BASE+165)
-					/* 166 was sys_vm86 */
-					/* 167 was sys_query_module */
-#define __NR_poll			(__NR_SYSCALL_BASE+168)
-#define __NR_nfsservctl			(__NR_SYSCALL_BASE+169)
-#define __NR_setresgid			(__NR_SYSCALL_BASE+170)
-#define __NR_getresgid			(__NR_SYSCALL_BASE+171)
-#define __NR_prctl			(__NR_SYSCALL_BASE+172)
-#define __NR_rt_sigreturn		(__NR_SYSCALL_BASE+173)
-#define __NR_rt_sigaction		(__NR_SYSCALL_BASE+174)
-#define __NR_rt_sigprocmask		(__NR_SYSCALL_BASE+175)
-#define __NR_rt_sigpending		(__NR_SYSCALL_BASE+176)
-#define __NR_rt_sigtimedwait		(__NR_SYSCALL_BASE+177)
-#define __NR_rt_sigqueueinfo		(__NR_SYSCALL_BASE+178)
-#define __NR_rt_sigsuspend		(__NR_SYSCALL_BASE+179)
-#define __NR_pread64			(__NR_SYSCALL_BASE+180)
-#define __NR_pwrite64			(__NR_SYSCALL_BASE+181)
-#define __NR_chown			(__NR_SYSCALL_BASE+182)
-#define __NR_getcwd			(__NR_SYSCALL_BASE+183)
-#define __NR_capget			(__NR_SYSCALL_BASE+184)
-#define __NR_capset			(__NR_SYSCALL_BASE+185)
-#define __NR_sigaltstack		(__NR_SYSCALL_BASE+186)
-#define __NR_sendfile			(__NR_SYSCALL_BASE+187)
-					/* 188 reserved */
-					/* 189 reserved */
-#define __NR_vfork			(__NR_SYSCALL_BASE+190)
-#define __NR_ugetrlimit			(__NR_SYSCALL_BASE+191)	/* SuS compliant getrlimit */
-#define __NR_mmap2			(__NR_SYSCALL_BASE+192)
-#define __NR_truncate64			(__NR_SYSCALL_BASE+193)
-#define __NR_ftruncate64		(__NR_SYSCALL_BASE+194)
-#define __NR_stat64			(__NR_SYSCALL_BASE+195)
-#define __NR_lstat64			(__NR_SYSCALL_BASE+196)
-#define __NR_fstat64			(__NR_SYSCALL_BASE+197)
-#define __NR_lchown32			(__NR_SYSCALL_BASE+198)
-#define __NR_getuid32			(__NR_SYSCALL_BASE+199)
-#define __NR_getgid32			(__NR_SYSCALL_BASE+200)
-#define __NR_geteuid32			(__NR_SYSCALL_BASE+201)
-#define __NR_getegid32			(__NR_SYSCALL_BASE+202)
-#define __NR_setreuid32			(__NR_SYSCALL_BASE+203)
-#define __NR_setregid32			(__NR_SYSCALL_BASE+204)
-#define __NR_getgroups32		(__NR_SYSCALL_BASE+205)
-#define __NR_setgroups32		(__NR_SYSCALL_BASE+206)
-#define __NR_fchown32			(__NR_SYSCALL_BASE+207)
-#define __NR_setresuid32		(__NR_SYSCALL_BASE+208)
-#define __NR_getresuid32		(__NR_SYSCALL_BASE+209)
-#define __NR_setresgid32		(__NR_SYSCALL_BASE+210)
-#define __NR_getresgid32		(__NR_SYSCALL_BASE+211)
-#define __NR_chown32			(__NR_SYSCALL_BASE+212)
-#define __NR_setuid32			(__NR_SYSCALL_BASE+213)
-#define __NR_setgid32			(__NR_SYSCALL_BASE+214)
-#define __NR_setfsuid32			(__NR_SYSCALL_BASE+215)
-#define __NR_setfsgid32			(__NR_SYSCALL_BASE+216)
-#define __NR_getdents64			(__NR_SYSCALL_BASE+217)
-#define __NR_pivot_root			(__NR_SYSCALL_BASE+218)
-#define __NR_mincore			(__NR_SYSCALL_BASE+219)
-#define __NR_madvise			(__NR_SYSCALL_BASE+220)
-#define __NR_fcntl64			(__NR_SYSCALL_BASE+221)
-					/* 222 for tux */
-					/* 223 is unused */
-#define __NR_gettid			(__NR_SYSCALL_BASE+224)
-#define __NR_readahead			(__NR_SYSCALL_BASE+225)
-#define __NR_setxattr			(__NR_SYSCALL_BASE+226)
-#define __NR_lsetxattr			(__NR_SYSCALL_BASE+227)
-#define __NR_fsetxattr			(__NR_SYSCALL_BASE+228)
-#define __NR_getxattr			(__NR_SYSCALL_BASE+229)
-#define __NR_lgetxattr			(__NR_SYSCALL_BASE+230)
-#define __NR_fgetxattr			(__NR_SYSCALL_BASE+231)
-#define __NR_listxattr			(__NR_SYSCALL_BASE+232)
-#define __NR_llistxattr			(__NR_SYSCALL_BASE+233)
-#define __NR_flistxattr			(__NR_SYSCALL_BASE+234)
-#define __NR_removexattr		(__NR_SYSCALL_BASE+235)
-#define __NR_lremovexattr		(__NR_SYSCALL_BASE+236)
-#define __NR_fremovexattr		(__NR_SYSCALL_BASE+237)
-#define __NR_tkill			(__NR_SYSCALL_BASE+238)
-#define __NR_sendfile64			(__NR_SYSCALL_BASE+239)
-#define __NR_futex			(__NR_SYSCALL_BASE+240)
-#define __NR_sched_setaffinity		(__NR_SYSCALL_BASE+241)
-#define __NR_sched_getaffinity		(__NR_SYSCALL_BASE+242)
-#define __NR_io_setup			(__NR_SYSCALL_BASE+243)
-#define __NR_io_destroy			(__NR_SYSCALL_BASE+244)
-#define __NR_io_getevents		(__NR_SYSCALL_BASE+245)
-#define __NR_io_submit			(__NR_SYSCALL_BASE+246)
-#define __NR_io_cancel			(__NR_SYSCALL_BASE+247)
-#define __NR_exit_group			(__NR_SYSCALL_BASE+248)
-#define __NR_lookup_dcookie		(__NR_SYSCALL_BASE+249)
-#define __NR_epoll_create		(__NR_SYSCALL_BASE+250)
-#define __NR_epoll_ctl			(__NR_SYSCALL_BASE+251)
-#define __NR_epoll_wait			(__NR_SYSCALL_BASE+252)
-#define __NR_remap_file_pages		(__NR_SYSCALL_BASE+253)
-					/* 254 for set_thread_area */
-					/* 255 for get_thread_area */
-#define __NR_set_tid_address		(__NR_SYSCALL_BASE+256)
-#define __NR_timer_create		(__NR_SYSCALL_BASE+257)
-#define __NR_timer_settime		(__NR_SYSCALL_BASE+258)
-#define __NR_timer_gettime		(__NR_SYSCALL_BASE+259)
-#define __NR_timer_getoverrun		(__NR_SYSCALL_BASE+260)
-#define __NR_timer_delete		(__NR_SYSCALL_BASE+261)
-#define __NR_clock_settime		(__NR_SYSCALL_BASE+262)
-#define __NR_clock_gettime		(__NR_SYSCALL_BASE+263)
-#define __NR_clock_getres		(__NR_SYSCALL_BASE+264)
-#define __NR_clock_nanosleep		(__NR_SYSCALL_BASE+265)
-#define __NR_statfs64			(__NR_SYSCALL_BASE+266)
-#define __NR_fstatfs64			(__NR_SYSCALL_BASE+267)
-#define __NR_tgkill			(__NR_SYSCALL_BASE+268)
-#define __NR_utimes			(__NR_SYSCALL_BASE+269)
-#define __NR_arm_fadvise64_64		(__NR_SYSCALL_BASE+270)
-#define __NR_pciconfig_iobase		(__NR_SYSCALL_BASE+271)
-#define __NR_pciconfig_read		(__NR_SYSCALL_BASE+272)
-#define __NR_pciconfig_write		(__NR_SYSCALL_BASE+273)
-#define __NR_mq_open			(__NR_SYSCALL_BASE+274)
-#define __NR_mq_unlink			(__NR_SYSCALL_BASE+275)
-#define __NR_mq_timedsend		(__NR_SYSCALL_BASE+276)
-#define __NR_mq_timedreceive		(__NR_SYSCALL_BASE+277)
-#define __NR_mq_notify			(__NR_SYSCALL_BASE+278)
-#define __NR_mq_getsetattr		(__NR_SYSCALL_BASE+279)
-#define __NR_waitid			(__NR_SYSCALL_BASE+280)
-#define __NR_socket			(__NR_SYSCALL_BASE+281)
-#define __NR_bind			(__NR_SYSCALL_BASE+282)
-#define __NR_connect			(__NR_SYSCALL_BASE+283)
-#define __NR_listen			(__NR_SYSCALL_BASE+284)
-#define __NR_accept			(__NR_SYSCALL_BASE+285)
-#define __NR_getsockname		(__NR_SYSCALL_BASE+286)
-#define __NR_getpeername		(__NR_SYSCALL_BASE+287)
-#define __NR_socketpair			(__NR_SYSCALL_BASE+288)
-#define __NR_send			(__NR_SYSCALL_BASE+289)
-#define __NR_sendto			(__NR_SYSCALL_BASE+290)
-#define __NR_recv			(__NR_SYSCALL_BASE+291)
-#define __NR_recvfrom			(__NR_SYSCALL_BASE+292)
-#define __NR_shutdown			(__NR_SYSCALL_BASE+293)
-#define __NR_setsockopt			(__NR_SYSCALL_BASE+294)
-#define __NR_getsockopt			(__NR_SYSCALL_BASE+295)
-#define __NR_sendmsg			(__NR_SYSCALL_BASE+296)
-#define __NR_recvmsg			(__NR_SYSCALL_BASE+297)
-#define __NR_semop			(__NR_SYSCALL_BASE+298)
-#define __NR_semget			(__NR_SYSCALL_BASE+299)
-#define __NR_semctl			(__NR_SYSCALL_BASE+300)
-#define __NR_msgsnd			(__NR_SYSCALL_BASE+301)
-#define __NR_msgrcv			(__NR_SYSCALL_BASE+302)
-#define __NR_msgget			(__NR_SYSCALL_BASE+303)
-#define __NR_msgctl			(__NR_SYSCALL_BASE+304)
-#define __NR_shmat			(__NR_SYSCALL_BASE+305)
-#define __NR_shmdt			(__NR_SYSCALL_BASE+306)
-#define __NR_shmget			(__NR_SYSCALL_BASE+307)
-#define __NR_shmctl			(__NR_SYSCALL_BASE+308)
-#define __NR_add_key			(__NR_SYSCALL_BASE+309)
-#define __NR_request_key		(__NR_SYSCALL_BASE+310)
-#define __NR_keyctl			(__NR_SYSCALL_BASE+311)
-#define __NR_semtimedop			(__NR_SYSCALL_BASE+312)
-#define __NR_vserver			(__NR_SYSCALL_BASE+313)
-#define __NR_ioprio_set			(__NR_SYSCALL_BASE+314)
-#define __NR_ioprio_get			(__NR_SYSCALL_BASE+315)
-#define __NR_inotify_init		(__NR_SYSCALL_BASE+316)
-#define __NR_inotify_add_watch		(__NR_SYSCALL_BASE+317)
-#define __NR_inotify_rm_watch		(__NR_SYSCALL_BASE+318)
-#define __NR_mbind			(__NR_SYSCALL_BASE+319)
-#define __NR_get_mempolicy		(__NR_SYSCALL_BASE+320)
-#define __NR_set_mempolicy		(__NR_SYSCALL_BASE+321)
-#define __NR_openat			(__NR_SYSCALL_BASE+322)
-#define __NR_mkdirat			(__NR_SYSCALL_BASE+323)
-#define __NR_mknodat			(__NR_SYSCALL_BASE+324)
-#define __NR_fchownat			(__NR_SYSCALL_BASE+325)
-#define __NR_futimesat			(__NR_SYSCALL_BASE+326)
-#define __NR_fstatat64			(__NR_SYSCALL_BASE+327)
-#define __NR_unlinkat			(__NR_SYSCALL_BASE+328)
-#define __NR_renameat			(__NR_SYSCALL_BASE+329)
-#define __NR_linkat			(__NR_SYSCALL_BASE+330)
-#define __NR_symlinkat			(__NR_SYSCALL_BASE+331)
-#define __NR_readlinkat			(__NR_SYSCALL_BASE+332)
-#define __NR_fchmodat			(__NR_SYSCALL_BASE+333)
-#define __NR_faccessat			(__NR_SYSCALL_BASE+334)
-#define __NR_pselect6			(__NR_SYSCALL_BASE+335)
-#define __NR_ppoll			(__NR_SYSCALL_BASE+336)
-#define __NR_unshare			(__NR_SYSCALL_BASE+337)
-#define __NR_set_robust_list		(__NR_SYSCALL_BASE+338)
-#define __NR_get_robust_list		(__NR_SYSCALL_BASE+339)
-#define __NR_splice			(__NR_SYSCALL_BASE+340)
-#define __NR_arm_sync_file_range	(__NR_SYSCALL_BASE+341)
+#include <asm/unistd-common.h>
 #define __NR_sync_file_range2		__NR_arm_sync_file_range
-#define __NR_tee			(__NR_SYSCALL_BASE+342)
-#define __NR_vmsplice			(__NR_SYSCALL_BASE+343)
-#define __NR_move_pages			(__NR_SYSCALL_BASE+344)
-#define __NR_getcpu			(__NR_SYSCALL_BASE+345)
-#define __NR_epoll_pwait		(__NR_SYSCALL_BASE+346)
-#define __NR_kexec_load			(__NR_SYSCALL_BASE+347)
-#define __NR_utimensat			(__NR_SYSCALL_BASE+348)
-#define __NR_signalfd			(__NR_SYSCALL_BASE+349)
-#define __NR_timerfd_create		(__NR_SYSCALL_BASE+350)
-#define __NR_eventfd			(__NR_SYSCALL_BASE+351)
-#define __NR_fallocate			(__NR_SYSCALL_BASE+352)
-#define __NR_timerfd_settime		(__NR_SYSCALL_BASE+353)
-#define __NR_timerfd_gettime		(__NR_SYSCALL_BASE+354)
-#define __NR_signalfd4			(__NR_SYSCALL_BASE+355)
-#define __NR_eventfd2			(__NR_SYSCALL_BASE+356)
-#define __NR_epoll_create1		(__NR_SYSCALL_BASE+357)
-#define __NR_dup3			(__NR_SYSCALL_BASE+358)
-#define __NR_pipe2			(__NR_SYSCALL_BASE+359)
-#define __NR_inotify_init1		(__NR_SYSCALL_BASE+360)
-#define __NR_preadv			(__NR_SYSCALL_BASE+361)
-#define __NR_pwritev			(__NR_SYSCALL_BASE+362)
-#define __NR_rt_tgsigqueueinfo		(__NR_SYSCALL_BASE+363)
-#define __NR_perf_event_open		(__NR_SYSCALL_BASE+364)
-#define __NR_recvmmsg			(__NR_SYSCALL_BASE+365)
-#define __NR_accept4			(__NR_SYSCALL_BASE+366)
-#define __NR_fanotify_init		(__NR_SYSCALL_BASE+367)
-#define __NR_fanotify_mark		(__NR_SYSCALL_BASE+368)
-#define __NR_prlimit64			(__NR_SYSCALL_BASE+369)
-#define __NR_name_to_handle_at		(__NR_SYSCALL_BASE+370)
-#define __NR_open_by_handle_at		(__NR_SYSCALL_BASE+371)
-#define __NR_clock_adjtime		(__NR_SYSCALL_BASE+372)
-#define __NR_syncfs			(__NR_SYSCALL_BASE+373)
-#define __NR_sendmmsg			(__NR_SYSCALL_BASE+374)
-#define __NR_setns			(__NR_SYSCALL_BASE+375)
-#define __NR_process_vm_readv		(__NR_SYSCALL_BASE+376)
-#define __NR_process_vm_writev		(__NR_SYSCALL_BASE+377)
-#define __NR_kcmp			(__NR_SYSCALL_BASE+378)
-#define __NR_finit_module		(__NR_SYSCALL_BASE+379)
-#define __NR_sched_setattr		(__NR_SYSCALL_BASE+380)
-#define __NR_sched_getattr		(__NR_SYSCALL_BASE+381)
-#define __NR_renameat2			(__NR_SYSCALL_BASE+382)
-#define __NR_seccomp			(__NR_SYSCALL_BASE+383)
-#define __NR_getrandom			(__NR_SYSCALL_BASE+384)
-#define __NR_memfd_create		(__NR_SYSCALL_BASE+385)
-#define __NR_bpf			(__NR_SYSCALL_BASE+386)
-#define __NR_execveat			(__NR_SYSCALL_BASE+387)
-#define __NR_userfaultfd		(__NR_SYSCALL_BASE+388)
-#define __NR_membarrier			(__NR_SYSCALL_BASE+389)
-#define __NR_mlock2			(__NR_SYSCALL_BASE+390)
-#define __NR_copy_file_range		(__NR_SYSCALL_BASE+391)
-#define __NR_preadv2			(__NR_SYSCALL_BASE+392)
-#define __NR_pwritev2			(__NR_SYSCALL_BASE+393)
 
 /*
  * The following SWIs are ARM private.
@@ -431,24 +36,4 @@
 #define __ARM_NR_usr32			(__ARM_NR_BASE+4)
 #define __ARM_NR_set_tls		(__ARM_NR_BASE+5)
 
-/*
- * The following syscalls are obsolete and no longer available for EABI.
- */
-#if !defined(__KERNEL__)
-#if defined(__ARM_EABI__)
-#undef __NR_time
-#undef __NR_umount
-#undef __NR_stime
-#undef __NR_alarm
-#undef __NR_utime
-#undef __NR_getrlimit
-#undef __NR_select
-#undef __NR_readdir
-#undef __NR_mmap
-#undef __NR_socketcall
-#undef __NR_syscall
-#undef __NR_ipc
-#endif
-#endif
-
 #endif /* _UAPI__ASM_ARM_UNISTD_H */
diff --git a/arch/arm/kernel/calls.S b/arch/arm/kernel/calls.S
deleted file mode 100644
index 703fa0f3cd8f..000000000000
--- a/arch/arm/kernel/calls.S
+++ /dev/null
@@ -1,412 +0,0 @@
-/*
- *  linux/arch/arm/kernel/calls.S
- *
- *  Copyright (C) 1995-2005 Russell King
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- *  This file is included thrice in entry-common.S
- */
-/* 0 */		CALL(sys_restart_syscall)
-		CALL(sys_exit)
-		CALL(sys_fork)
-		CALL(sys_read)
-		CALL(sys_write)
-/* 5 */		CALL(sys_open)
-		CALL(sys_close)
-		CALL(sys_ni_syscall)		/* was sys_waitpid */
-		CALL(sys_creat)
-		CALL(sys_link)
-/* 10 */	CALL(sys_unlink)
-		CALL(sys_execve)
-		CALL(sys_chdir)
-		CALL(OBSOLETE(sys_time))	/* used by libc4 */
-		CALL(sys_mknod)
-/* 15 */	CALL(sys_chmod)
-		CALL(sys_lchown16)
-		CALL(sys_ni_syscall)		/* was sys_break */
-		CALL(sys_ni_syscall)		/* was sys_stat */
-		CALL(sys_lseek)
-/* 20 */	CALL(sys_getpid)
-		CALL(sys_mount)
-		CALL(OBSOLETE(sys_oldumount))	/* used by libc4 */
-		CALL(sys_setuid16)
-		CALL(sys_getuid16)
-/* 25 */	CALL(OBSOLETE(sys_stime))
-		CALL(sys_ptrace)
-		CALL(OBSOLETE(sys_alarm))	/* used by libc4 */
-		CALL(sys_ni_syscall)		/* was sys_fstat */
-		CALL(sys_pause)
-/* 30 */	CALL(OBSOLETE(sys_utime))	/* used by libc4 */
-		CALL(sys_ni_syscall)		/* was sys_stty */
-		CALL(sys_ni_syscall)		/* was sys_getty */
-		CALL(sys_access)
-		CALL(sys_nice)
-/* 35 */	CALL(sys_ni_syscall)		/* was sys_ftime */
-		CALL(sys_sync)
-		CALL(sys_kill)
-		CALL(sys_rename)
-		CALL(sys_mkdir)
-/* 40 */	CALL(sys_rmdir)
-		CALL(sys_dup)
-		CALL(sys_pipe)
-		CALL(sys_times)
-		CALL(sys_ni_syscall)		/* was sys_prof */
-/* 45 */	CALL(sys_brk)
-		CALL(sys_setgid16)
-		CALL(sys_getgid16)
-		CALL(sys_ni_syscall)		/* was sys_signal */
-		CALL(sys_geteuid16)
-/* 50 */	CALL(sys_getegid16)
-		CALL(sys_acct)
-		CALL(sys_umount)
-		CALL(sys_ni_syscall)		/* was sys_lock */
-		CALL(sys_ioctl)
-/* 55 */	CALL(sys_fcntl)
-		CALL(sys_ni_syscall)		/* was sys_mpx */
-		CALL(sys_setpgid)
-		CALL(sys_ni_syscall)		/* was sys_ulimit */
-		CALL(sys_ni_syscall)		/* was sys_olduname */
-/* 60 */	CALL(sys_umask)
-		CALL(sys_chroot)
-		CALL(sys_ustat)
-		CALL(sys_dup2)
-		CALL(sys_getppid)
-/* 65 */	CALL(sys_getpgrp)
-		CALL(sys_setsid)
-		CALL(sys_sigaction)
-		CALL(sys_ni_syscall)		/* was sys_sgetmask */
-		CALL(sys_ni_syscall)		/* was sys_ssetmask */
-/* 70 */	CALL(sys_setreuid16)
-		CALL(sys_setregid16)
-		CALL(sys_sigsuspend)
-		CALL(sys_sigpending)
-		CALL(sys_sethostname)
-/* 75 */	CALL(sys_setrlimit)
-		CALL(OBSOLETE(sys_old_getrlimit)) /* used by libc4 */
-		CALL(sys_getrusage)
-		CALL(sys_gettimeofday)
-		CALL(sys_settimeofday)
-/* 80 */	CALL(sys_getgroups16)
-		CALL(sys_setgroups16)
-		CALL(OBSOLETE(sys_old_select))	/* used by libc4 */
-		CALL(sys_symlink)
-		CALL(sys_ni_syscall)		/* was sys_lstat */
-/* 85 */	CALL(sys_readlink)
-		CALL(sys_uselib)
-		CALL(sys_swapon)
-		CALL(sys_reboot)
-		CALL(OBSOLETE(sys_old_readdir))	/* used by libc4 */
-/* 90 */	CALL(OBSOLETE(sys_old_mmap))	/* used by libc4 */
-		CALL(sys_munmap)
-		CALL(sys_truncate)
-		CALL(sys_ftruncate)
-		CALL(sys_fchmod)
-/* 95 */	CALL(sys_fchown16)
-		CALL(sys_getpriority)
-		CALL(sys_setpriority)
-		CALL(sys_ni_syscall)		/* was sys_profil */
-		CALL(sys_statfs)
-/* 100 */	CALL(sys_fstatfs)
-		CALL(sys_ni_syscall)		/* sys_ioperm */
-		CALL(OBSOLETE(ABI(sys_socketcall, sys_oabi_socketcall)))
-		CALL(sys_syslog)
-		CALL(sys_setitimer)
-/* 105 */	CALL(sys_getitimer)
-		CALL(sys_newstat)
-		CALL(sys_newlstat)
-		CALL(sys_newfstat)
-		CALL(sys_ni_syscall)		/* was sys_uname */
-/* 110 */	CALL(sys_ni_syscall)		/* was sys_iopl */
-		CALL(sys_vhangup)
-		CALL(sys_ni_syscall)
-		CALL(OBSOLETE(sys_syscall))	/* call a syscall */
-		CALL(sys_wait4)
-/* 115 */	CALL(sys_swapoff)
-		CALL(sys_sysinfo)
-		CALL(OBSOLETE(ABI(sys_ipc, sys_oabi_ipc)))
-		CALL(sys_fsync)
-		CALL(sys_sigreturn_wrapper)
-/* 120 */	CALL(sys_clone)
-		CALL(sys_setdomainname)
-		CALL(sys_newuname)
-		CALL(sys_ni_syscall)		/* modify_ldt */
-		CALL(sys_adjtimex)
-/* 125 */	CALL(sys_mprotect)
-		CALL(sys_sigprocmask)
-		CALL(sys_ni_syscall)		/* was sys_create_module */
-		CALL(sys_init_module)
-		CALL(sys_delete_module)
-/* 130 */	CALL(sys_ni_syscall)		/* was sys_get_kernel_syms */
-		CALL(sys_quotactl)
-		CALL(sys_getpgid)
-		CALL(sys_fchdir)
-		CALL(sys_bdflush)
-/* 135 */	CALL(sys_sysfs)
-		CALL(sys_personality)
-		CALL(sys_ni_syscall)		/* reserved for afs_syscall */
-		CALL(sys_setfsuid16)
-		CALL(sys_setfsgid16)
-/* 140 */	CALL(sys_llseek)
-		CALL(sys_getdents)
-		CALL(sys_select)
-		CALL(sys_flock)
-		CALL(sys_msync)
-/* 145 */	CALL(sys_readv)
-		CALL(sys_writev)
-		CALL(sys_getsid)
-		CALL(sys_fdatasync)
-		CALL(sys_sysctl)
-/* 150 */	CALL(sys_mlock)
-		CALL(sys_munlock)
-		CALL(sys_mlockall)
-		CALL(sys_munlockall)
-		CALL(sys_sched_setparam)
-/* 155 */	CALL(sys_sched_getparam)
-		CALL(sys_sched_setscheduler)
-		CALL(sys_sched_getscheduler)
-		CALL(sys_sched_yield)
-		CALL(sys_sched_get_priority_max)
-/* 160 */	CALL(sys_sched_get_priority_min)
-		CALL(sys_sched_rr_get_interval)
-		CALL(sys_nanosleep)
-		CALL(sys_mremap)
-		CALL(sys_setresuid16)
-/* 165 */	CALL(sys_getresuid16)
-		CALL(sys_ni_syscall)		/* vm86 */
-		CALL(sys_ni_syscall)		/* was sys_query_module */
-		CALL(sys_poll)
-		CALL(sys_ni_syscall)		/* was nfsservctl */
-/* 170 */	CALL(sys_setresgid16)
-		CALL(sys_getresgid16)
-		CALL(sys_prctl)
-		CALL(sys_rt_sigreturn_wrapper)
-		CALL(sys_rt_sigaction)
-/* 175 */	CALL(sys_rt_sigprocmask)
-		CALL(sys_rt_sigpending)
-		CALL(sys_rt_sigtimedwait)
-		CALL(sys_rt_sigqueueinfo)
-		CALL(sys_rt_sigsuspend)
-/* 180 */	CALL(ABI(sys_pread64, sys_oabi_pread64))
-		CALL(ABI(sys_pwrite64, sys_oabi_pwrite64))
-		CALL(sys_chown16)
-		CALL(sys_getcwd)
-		CALL(sys_capget)
-/* 185 */	CALL(sys_capset)
-		CALL(sys_sigaltstack)
-		CALL(sys_sendfile)
-		CALL(sys_ni_syscall)		/* getpmsg */
-		CALL(sys_ni_syscall)		/* putpmsg */
-/* 190 */	CALL(sys_vfork)
-		CALL(sys_getrlimit)
-		CALL(sys_mmap2)
-		CALL(ABI(sys_truncate64, sys_oabi_truncate64))
-		CALL(ABI(sys_ftruncate64, sys_oabi_ftruncate64))
-/* 195 */	CALL(ABI(sys_stat64, sys_oabi_stat64))
-		CALL(ABI(sys_lstat64, sys_oabi_lstat64))
-		CALL(ABI(sys_fstat64, sys_oabi_fstat64))
-		CALL(sys_lchown)
-		CALL(sys_getuid)
-/* 200 */	CALL(sys_getgid)
-		CALL(sys_geteuid)
-		CALL(sys_getegid)
-		CALL(sys_setreuid)
-		CALL(sys_setregid)
-/* 205 */	CALL(sys_getgroups)
-		CALL(sys_setgroups)
-		CALL(sys_fchown)
-		CALL(sys_setresuid)
-		CALL(sys_getresuid)
-/* 210 */	CALL(sys_setresgid)
-		CALL(sys_getresgid)
-		CALL(sys_chown)
-		CALL(sys_setuid)
-		CALL(sys_setgid)
-/* 215 */	CALL(sys_setfsuid)
-		CALL(sys_setfsgid)
-		CALL(sys_getdents64)
-		CALL(sys_pivot_root)
-		CALL(sys_mincore)
-/* 220 */	CALL(sys_madvise)
-		CALL(ABI(sys_fcntl64, sys_oabi_fcntl64))
-		CALL(sys_ni_syscall) /* TUX */
-		CALL(sys_ni_syscall)
-		CALL(sys_gettid)
-/* 225 */	CALL(ABI(sys_readahead, sys_oabi_readahead))
-		CALL(sys_setxattr)
-		CALL(sys_lsetxattr)
-		CALL(sys_fsetxattr)
-		CALL(sys_getxattr)
-/* 230 */	CALL(sys_lgetxattr)
-		CALL(sys_fgetxattr)
-		CALL(sys_listxattr)
-		CALL(sys_llistxattr)
-		CALL(sys_flistxattr)
-/* 235 */	CALL(sys_removexattr)
-		CALL(sys_lremovexattr)
-		CALL(sys_fremovexattr)
-		CALL(sys_tkill)
-		CALL(sys_sendfile64)
-/* 240 */	CALL(sys_futex)
-		CALL(sys_sched_setaffinity)
-		CALL(sys_sched_getaffinity)
-		CALL(sys_io_setup)
-		CALL(sys_io_destroy)
-/* 245 */	CALL(sys_io_getevents)
-		CALL(sys_io_submit)
-		CALL(sys_io_cancel)
-		CALL(sys_exit_group)
-		CALL(sys_lookup_dcookie)
-/* 250 */	CALL(sys_epoll_create)
-		CALL(ABI(sys_epoll_ctl, sys_oabi_epoll_ctl))
-		CALL(ABI(sys_epoll_wait, sys_oabi_epoll_wait))
-		CALL(sys_remap_file_pages)
-		CALL(sys_ni_syscall)	/* sys_set_thread_area */
-/* 255 */	CALL(sys_ni_syscall)	/* sys_get_thread_area */
-		CALL(sys_set_tid_address)
-		CALL(sys_timer_create)
-		CALL(sys_timer_settime)
-		CALL(sys_timer_gettime)
-/* 260 */	CALL(sys_timer_getoverrun)
-		CALL(sys_timer_delete)
-		CALL(sys_clock_settime)
-		CALL(sys_clock_gettime)
-		CALL(sys_clock_getres)
-/* 265 */	CALL(sys_clock_nanosleep)
-		CALL(sys_statfs64_wrapper)
-		CALL(sys_fstatfs64_wrapper)
-		CALL(sys_tgkill)
-		CALL(sys_utimes)
-/* 270 */	CALL(sys_arm_fadvise64_64)
-		CALL(sys_pciconfig_iobase)
-		CALL(sys_pciconfig_read)
-		CALL(sys_pciconfig_write)
-		CALL(sys_mq_open)
-/* 275 */	CALL(sys_mq_unlink)
-		CALL(sys_mq_timedsend)
-		CALL(sys_mq_timedreceive)
-		CALL(sys_mq_notify)
-		CALL(sys_mq_getsetattr)
-/* 280 */	CALL(sys_waitid)
-		CALL(sys_socket)
-		CALL(ABI(sys_bind, sys_oabi_bind))
-		CALL(ABI(sys_connect, sys_oabi_connect))
-		CALL(sys_listen)
-/* 285 */	CALL(sys_accept)
-		CALL(sys_getsockname)
-		CALL(sys_getpeername)
-		CALL(sys_socketpair)
-		CALL(sys_send)
-/* 290 */	CALL(ABI(sys_sendto, sys_oabi_sendto))
-		CALL(sys_recv)
-		CALL(sys_recvfrom)
-		CALL(sys_shutdown)
-		CALL(sys_setsockopt)
-/* 295 */	CALL(sys_getsockopt)
-		CALL(ABI(sys_sendmsg, sys_oabi_sendmsg))
-		CALL(sys_recvmsg)
-		CALL(ABI(sys_semop, sys_oabi_semop))
-		CALL(sys_semget)
-/* 300 */	CALL(sys_semctl)
-		CALL(sys_msgsnd)
-		CALL(sys_msgrcv)
-		CALL(sys_msgget)
-		CALL(sys_msgctl)
-/* 305 */	CALL(sys_shmat)
-		CALL(sys_shmdt)
-		CALL(sys_shmget)
-		CALL(sys_shmctl)
-		CALL(sys_add_key)
-/* 310 */	CALL(sys_request_key)
-		CALL(sys_keyctl)
-		CALL(ABI(sys_semtimedop, sys_oabi_semtimedop))
-/* vserver */	CALL(sys_ni_syscall)
-		CALL(sys_ioprio_set)
-/* 315 */	CALL(sys_ioprio_get)
-		CALL(sys_inotify_init)
-		CALL(sys_inotify_add_watch)
-		CALL(sys_inotify_rm_watch)
-		CALL(sys_mbind)
-/* 320 */	CALL(sys_get_mempolicy)
-		CALL(sys_set_mempolicy)
-		CALL(sys_openat)
-		CALL(sys_mkdirat)
-		CALL(sys_mknodat)
-/* 325 */	CALL(sys_fchownat)
-		CALL(sys_futimesat)
-		CALL(ABI(sys_fstatat64,  sys_oabi_fstatat64))
-		CALL(sys_unlinkat)
-		CALL(sys_renameat)
-/* 330 */	CALL(sys_linkat)
-		CALL(sys_symlinkat)
-		CALL(sys_readlinkat)
-		CALL(sys_fchmodat)
-		CALL(sys_faccessat)
-/* 335 */	CALL(sys_pselect6)
-		CALL(sys_ppoll)
-		CALL(sys_unshare)
-		CALL(sys_set_robust_list)
-		CALL(sys_get_robust_list)
-/* 340 */	CALL(sys_splice)
-		CALL(sys_sync_file_range2)
-		CALL(sys_tee)
-		CALL(sys_vmsplice)
-		CALL(sys_move_pages)
-/* 345 */	CALL(sys_getcpu)
-		CALL(sys_epoll_pwait)
-		CALL(sys_kexec_load)
-		CALL(sys_utimensat)
-		CALL(sys_signalfd)
-/* 350 */	CALL(sys_timerfd_create)
-		CALL(sys_eventfd)
-		CALL(sys_fallocate)
-		CALL(sys_timerfd_settime)
-		CALL(sys_timerfd_gettime)
-/* 355 */	CALL(sys_signalfd4)
-		CALL(sys_eventfd2)
-		CALL(sys_epoll_create1)
-		CALL(sys_dup3)
-		CALL(sys_pipe2)
-/* 360 */	CALL(sys_inotify_init1)
-		CALL(sys_preadv)
-		CALL(sys_pwritev)
-		CALL(sys_rt_tgsigqueueinfo)
-		CALL(sys_perf_event_open)
-/* 365 */	CALL(sys_recvmmsg)
-		CALL(sys_accept4)
-		CALL(sys_fanotify_init)
-		CALL(sys_fanotify_mark)
-		CALL(sys_prlimit64)
-/* 370 */	CALL(sys_name_to_handle_at)
-		CALL(sys_open_by_handle_at)
-		CALL(sys_clock_adjtime)
-		CALL(sys_syncfs)
-		CALL(sys_sendmmsg)
-/* 375 */	CALL(sys_setns)
-		CALL(sys_process_vm_readv)
-		CALL(sys_process_vm_writev)
-		CALL(sys_kcmp)
-		CALL(sys_finit_module)
-/* 380 */	CALL(sys_sched_setattr)
-		CALL(sys_sched_getattr)
-		CALL(sys_renameat2)
-		CALL(sys_seccomp)
-		CALL(sys_getrandom)
-/* 385 */	CALL(sys_memfd_create)
-		CALL(sys_bpf)
-		CALL(sys_execveat)
-		CALL(sys_userfaultfd)
-		CALL(sys_membarrier)
-/* 390 */	CALL(sys_mlock2)
-		CALL(sys_copy_file_range)
-		CALL(sys_preadv2)
-		CALL(sys_pwritev2)
-#ifndef syscalls_counted
-.equ syscalls_padding, ((NR_syscalls + 3) & ~3) - NR_syscalls
-#define syscalls_counted
-#endif
-.rept syscalls_padding
-		CALL(sys_ni_syscall)
-.endr
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 10c3283d6c19..eb5cd77bf1d8 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -12,6 +12,11 @@
 #include <asm/unistd.h>
 #include <asm/ftrace.h>
 #include <asm/unwind.h>
+#ifdef CONFIG_AEABI
+#include <asm/unistd-oabi.h>
+#endif
+
+	.equ	NR_syscalls, __NR_syscalls
 
 #ifdef CONFIG_NEED_RET_TO_USER
 #include <mach/entry-macro.S>
@@ -120,21 +125,6 @@ ENTRY(ret_from_fork)
 	b	ret_slow_syscall
 ENDPROC(ret_from_fork)
 
-	.equ NR_syscalls,0
-#define CALL(x) .equ NR_syscalls,NR_syscalls+1
-#include "calls.S"
-
-/*
- * Ensure that the system call table is equal to __NR_syscalls,
- * which is the value the rest of the system sees
- */
-.ifne NR_syscalls - __NR_syscalls
-.error "__NR_syscalls is not equal to the size of the syscall table"
-.endif
-
-#undef CALL
-#define CALL(x) .long x
-
 /*=============================================================================
  * SWI handler
  *-----------------------------------------------------------------------------
@@ -291,22 +281,48 @@ ENDPROC(vector_swi)
 #endif
 	.ltorg
 
+	.macro	syscall_table_start, sym
+	.equ	__sys_nr, 0
+	.type	\sym, #object
+ENTRY(\sym)
+	.endm
+
+	.macro	syscall, nr, func
+	.ifgt	__sys_nr - \nr
+	.error	"Duplicated/unorded system call entry"
+	.endif
+	.rept	\nr - __sys_nr
+	.long	sys_ni_syscall
+	.endr
+	.long	\func
+	.equ	__sys_nr, \nr + 1
+	.endm
+
+	.macro	syscall_table_end, sym
+	.ifgt	__sys_nr - __NR_syscalls
+	.error	"System call table too big"
+	.endif
+	.rept	__NR_syscalls - __sys_nr
+	.long	sys_ni_syscall
+	.endr
+	.size	\sym, . - \sym
+	.endm
+
+#define NATIVE(nr, func) syscall nr, func
+
 /*
  * This is the syscall table declaration for native ABI syscalls.
  * With EABI a couple syscalls are obsolete and defined as sys_ni_syscall.
  */
-#define ABI(native, compat) native
+	syscall_table_start sys_call_table
+#define COMPAT(nr, native, compat) syscall nr, native
 #ifdef CONFIG_AEABI
-#define OBSOLETE(syscall) sys_ni_syscall
+#include <calls-eabi.S>
 #else
-#define OBSOLETE(syscall) syscall
+#include <calls-oabi.S>
 #endif
-
-	.type	sys_call_table, #object
-ENTRY(sys_call_table)
-#include "calls.S"
-#undef ABI
-#undef OBSOLETE
+#undef COMPAT
+	syscall_table_end sys_call_table
 
 /*============================================================================
  * Special system call wrappers
@@ -407,14 +423,10 @@ ENDPROC(sys_oabi_readahead)
  * Let's declare a second syscall table for old ABI binaries
  * using the compatibility syscall entries.
  */
-#define ABI(native, compat) compat
-#define OBSOLETE(syscall) syscall
-
-	.type	sys_oabi_call_table, #object
-ENTRY(sys_oabi_call_table)
-#include "calls.S"
-#undef ABI
-#undef OBSOLETE
+	syscall_table_start sys_oabi_call_table
+#define COMPAT(nr, native, compat) syscall nr, compat
+#include <calls-oabi.S>
+	syscall_table_end sys_oabi_call_table
 
 #endif
 
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index bdf48e4949ad..92eb5c3b486c 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -6,17 +6,31 @@
 
 gen := arch/$(ARCH)/include/generated
 kapi := $(gen)/asm
+uapi := $(gen)/uapi/asm
+syshdr := $(srctree)/$(src)/syscallhdr.sh
+sysnr := $(srctree)/$(src)/syscallnr.sh
+systbl := $(srctree)/$(src)/syscalltbl.sh
+syscall := $(srctree)/$(src)/syscall.tbl
 
-kapi-hdrs-y := $(kapi)/mach-types.h
+gen-y := $(gen)/calls-oabi.S
+gen-y += $(gen)/calls-eabi.S
+kapi-hdrs-y := $(kapi)/unistd-nr.h
+kapi-hdrs-y += $(kapi)/mach-types.h
+uapi-hdrs-y := $(uapi)/unistd-common.h
+uapi-hdrs-y += $(uapi)/unistd-oabi.h
+uapi-hdrs-y += $(uapi)/unistd-eabi.h
 
-targets += $(addprefix ../../../,$(kapi-hdrs-y))
+targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
 
-PHONY += kapi
+PHONY += kapi uapi
 
-kapi:	$(kapi-hdrs-y)
+kapi:	$(kapi-hdrs-y) $(gen-y)
+
+uapi:	$(uapi-hdrs-y)
 
 # Create output directory if not already present
-_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
+_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
+          $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
 
 quiet_cmd_gen_mach = GEN     $@
       cmd_gen_mach = mkdir -p $(dir $@) && \
@@ -25,3 +39,41 @@ quiet_cmd_gen_mach = GEN     $@
 
 $(kapi)/mach-types.h: $(src)/gen-mach-types $(src)/mach-types FORCE
 	$(call if_changed,gen_mach)
+
+quiet_cmd_syshdr = SYSHDR  $@
+      cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@' \
+		   '$(syshdr_abi_$(basetarget))' \
+		   '$(syshdr_pfx_$(basetarget))' \
+		   '__NR_SYSCALL_BASE'
+
+quiet_cmd_systbl = SYSTBL  $@
+      cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@' \
+		   '$(systbl_abi_$(basetarget))'
+
+quiet_cmd_sysnr  = SYSNR   $@
+      cmd_sysnr  = $(CONFIG_SHELL) '$(sysnr)' '$<' '$@' \
+		   '$(syshdr_abi_$(basetarget))'
+
+syshdr_abi_unistd-common := common
+$(uapi)/unistd-common.h: $(syscall) $(syshdr) FORCE
+	$(call if_changed,syshdr)
+
+syshdr_abi_unistd-oabi := oabi
+$(uapi)/unistd-oabi.h: $(syscall) $(syshdr) FORCE
+	$(call if_changed,syshdr)
+
+syshdr_abi_unistd-eabi := eabi
+$(uapi)/unistd-eabi.h: $(syscall) $(syshdr) FORCE
+	$(call if_changed,syshdr)
+
+sysnr_abi_unistd-nr := common,oabi,eabi,compat
+$(kapi)/unistd-nr.h: $(syscall) $(sysnr) FORCE
+	$(call if_changed,sysnr)
+
+systbl_abi_calls-oabi := common,oabi
+$(gen)/calls-oabi.S: $(syscall) $(systbl) FORCE
+	$(call if_changed,systbl)
+
+systbl_abi_calls-eabi := common,eabi
+$(gen)/calls-eabi.S: $(syscall) $(systbl) FORCE
+	$(call if_changed,systbl)
diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
new file mode 100644
index 000000000000..62285cbd09c0
--- /dev/null
+++ b/arch/arm/tools/syscall.tbl
@@ -0,0 +1,428 @@
+#
+# Linux system call numbers and entry vectors
+#
+# The format is:
+# <num>	<abi>	<name>			<entry point>			<oabi compat entry point>
+#
+# Where abi is:
+#  common - for system calls shared between oabi and eabi
+#  oabi   - for oabi-only system calls (may have compat)
+#  eabi   - for eabi-only system calls
+#
+# For each syscall number, "common" is mutually exclusive with oabi and eabi
+#
+0	common	restart_syscall		sys_restart_syscall
+1	common	exit			sys_exit
+2	common	fork			sys_fork
+3	common	read			sys_read
+4	common	write			sys_write
+5	common	open			sys_open
+6	common	close			sys_close
+# 7 was sys_waitpid
+8	common	creat			sys_creat
+9	common	link			sys_link
+10	common	unlink			sys_unlink
+11	common	execve			sys_execve
+12	common	chdir			sys_chdir
+13	oabi	time			sys_time
+14	common	mknod			sys_mknod
+15	common	chmod			sys_chmod
+16	common	lchown			sys_lchown16
+# 17 was sys_break
+# 18 was sys_stat
+19	common	lseek			sys_lseek
+20	common	getpid			sys_getpid
+21	common	mount			sys_mount
+22	oabi	umount			sys_oldumount
+23	common	setuid			sys_setuid16
+24	common	getuid			sys_getuid16
+25	oabi	stime			sys_stime
+26	common	ptrace			sys_ptrace
+27	oabi	alarm			sys_alarm
+# 28 was sys_fstat
+29	common	pause			sys_pause
+30	oabi	utime			sys_utime
+# 31 was sys_stty
+# 32 was sys_gtty
+33	common	access			sys_access
+34	common	nice			sys_nice
+# 35 was sys_ftime
+36	common	sync			sys_sync
+37	common	kill			sys_kill
+38	common	rename			sys_rename
+39	common	mkdir			sys_mkdir
+40	common	rmdir			sys_rmdir
+41	common	dup			sys_dup
+42	common	pipe			sys_pipe
+43	common	times			sys_times
+# 44 was sys_prof
+45	common	brk			sys_brk
+46	common	setgid			sys_setgid16
+47	common	getgid			sys_getgid16
+# 48 was sys_signal
+49	common	geteuid			sys_geteuid16
+50	common	getegid			sys_getegid16
+51	common	acct			sys_acct
+52	common	umount2			sys_umount
+# 53 was sys_lock
+54	common	ioctl			sys_ioctl
+55	common	fcntl			sys_fcntl
+# 56 was sys_mpx
+57	common	setpgid			sys_setpgid
+# 58 was sys_ulimit
+# 59 was sys_olduname
+60	common	umask			sys_umask
+61	common	chroot			sys_chroot
+62	common	ustat			sys_ustat
+63	common	dup2			sys_dup2
+64	common	getppid			sys_getppid
+65	common	getpgrp			sys_getpgrp
+66	common	setsid			sys_setsid
+67	common	sigaction		sys_sigaction
+# 68 was sys_sgetmask
+# 69 was sys_ssetmask
+70	common	setreuid		sys_setreuid16
+71	common	setregid		sys_setregid16
+72	common	sigsuspend		sys_sigsuspend
+73	common	sigpending		sys_sigpending
+74	common	sethostname		sys_sethostname
+75	common	setrlimit		sys_setrlimit
+# Back compat 2GB limited rlimit
+76	oabi	getrlimit		sys_old_getrlimit
+77	common	getrusage		sys_getrusage
+78	common	gettimeofday		sys_gettimeofday
+79	common	settimeofday		sys_settimeofday
+80	common	getgroups		sys_getgroups16
+81	common	setgroups		sys_setgroups16
+82	oabi	select			sys_old_select
+83	common	symlink			sys_symlink
+# 84 was sys_lstat
+85	common	readlink		sys_readlink
+86	common	uselib			sys_uselib
+87	common	swapon			sys_swapon
+88	common	reboot			sys_reboot
+89	oabi	readdir			sys_old_readdir
+90	oabi	mmap			sys_old_mmap
+91	common	munmap			sys_munmap
+92	common	truncate		sys_truncate
+93	common	ftruncate		sys_ftruncate
+94	common	fchmod			sys_fchmod
+95	common	fchown			sys_fchown16
+96	common	getpriority		sys_getpriority
+97	common	setpriority		sys_setpriority
+# 98 was sys_profil
+99	common	statfs			sys_statfs
+100	common	fstatfs			sys_fstatfs
+# 101 was sys_ioperm
+102	oabi	socketcall		sys_socketcall		sys_oabi_socketcall
+103	common	syslog			sys_syslog
+104	common	setitimer		sys_setitimer
+105	common	getitimer		sys_getitimer
+106	common	stat			sys_newstat
+107	common	lstat			sys_newlstat
+108	common	fstat			sys_newfstat
+# 109 was sys_uname
+# 110 was sys_iopl
+111	common	vhangup			sys_vhangup
+# 112 was sys_idle
+# syscall to call a syscall!
+113	oabi	syscall			sys_syscall
+114	common	wait4			sys_wait4
+115	common	swapoff			sys_swapoff
+116	common	sysinfo			sys_sysinfo
+117	oabi	ipc			sys_ipc			sys_oabi_ipc
+118	common	fsync			sys_fsync
+119	common	sigreturn		sys_sigreturn_wrapper
+120	common	clone			sys_clone
+121	common	setdomainname		sys_setdomainname
+122	common	uname			sys_newuname
+# 123 was sys_modify_ldt
+124	common	adjtimex		sys_adjtimex
+125	common	mprotect		sys_mprotect
+126	common	sigprocmask		sys_sigprocmask
+# 127 was sys_create_module
+128	common	init_module		sys_init_module
+129	common	delete_module		sys_delete_module
+# 130 was sys_get_kernel_syms
+131	common	quotactl		sys_quotactl
+132	common	getpgid			sys_getpgid
+133	common	fchdir			sys_fchdir
+134	common	bdflush			sys_bdflush
+135	common	sysfs			sys_sysfs
+136	common	personality		sys_personality
+# 137 was sys_afs_syscall
+138	common	setfsuid		sys_setfsuid16
+139	common	setfsgid		sys_setfsgid16
+140	common	_llseek			sys_llseek
+141	common	getdents		sys_getdents
+142	common	_newselect		sys_select
+143	common	flock			sys_flock
+144	common	msync			sys_msync
+145	common	readv			sys_readv
+146	common	writev			sys_writev
+147	common	getsid			sys_getsid
+148	common	fdatasync		sys_fdatasync
+149	common	_sysctl			sys_sysctl
+150	common	mlock			sys_mlock
+151	common	munlock			sys_munlock
+152	common	mlockall		sys_mlockall
+153	common	munlockall		sys_munlockall
+154	common	sched_setparam		sys_sched_setparam
+155	common	sched_getparam		sys_sched_getparam
+156	common	sched_setscheduler	sys_sched_setscheduler
+157	common	sched_getscheduler	sys_sched_getscheduler
+158	common	sched_yield		sys_sched_yield
+159	common	sched_get_priority_max	sys_sched_get_priority_max
+160	common	sched_get_priority_min	sys_sched_get_priority_min
+161	common	sched_rr_get_interval	sys_sched_rr_get_interval
+162	common	nanosleep		sys_nanosleep
+163	common	mremap			sys_mremap
+164	common	setresuid		sys_setresuid16
+165	common	getresuid		sys_getresuid16
+# 166 was sys_vm86
+# 167 was sys_query_module
+168	common	poll			sys_poll
+169	common	nfsservctl
+170	common	setresgid		sys_setresgid16
+171	common	getresgid		sys_getresgid16
+172	common	prctl			sys_prctl
+173	common	rt_sigreturn		sys_rt_sigreturn_wrapper
+174	common	rt_sigaction		sys_rt_sigaction
+175	common	rt_sigprocmask		sys_rt_sigprocmask
+176	common	rt_sigpending		sys_rt_sigpending
+177	common	rt_sigtimedwait		sys_rt_sigtimedwait
+178	common	rt_sigqueueinfo		sys_rt_sigqueueinfo
+179	common	rt_sigsuspend		sys_rt_sigsuspend
+180	oabi	pread64			sys_pread64		sys_oabi_pread64
+180	eabi	pread64			sys_pread64
+181	oabi	pwrite64		sys_pwrite64		sys_oabi_pwrite64
+181	eabi	pwrite64		sys_pwrite64
+182	common	chown			sys_chown16
+183	common	getcwd			sys_getcwd
+184	common	capget			sys_capget
+185	common	capset			sys_capset
+186	common	sigaltstack		sys_sigaltstack
+187	common	sendfile		sys_sendfile
+# 188 reserved
+# 189 reserved
+190	common	vfork			sys_vfork
+# SuS compliant getrlimit
+191	common	ugetrlimit		sys_getrlimit
+192	common	mmap2			sys_mmap2
+193	oabi	truncate64		sys_truncate64		sys_oabi_truncate64
+193	eabi	truncate64		sys_truncate64
+194	oabi	ftruncate64		sys_ftruncate64		sys_oabi_ftruncate64
+194	eabi	ftruncate64		sys_ftruncate64
+195	oabi	stat64			sys_stat64		sys_oabi_stat64
+195	eabi	stat64			sys_stat64
+196	oabi	lstat64			sys_lstat64		sys_oabi_lstat64
+196	eabi	lstat64			sys_lstat64
+197	oabi	fstat64			sys_fstat64		sys_oabi_fstat64
+197	eabi	fstat64			sys_fstat64
+198	common	lchown32		sys_lchown
+199	common	getuid32		sys_getuid
+200	common	getgid32		sys_getgid
+201	common	geteuid32		sys_geteuid
+202	common	getegid32		sys_getegid
+203	common	setreuid32		sys_setreuid
+204	common	setregid32		sys_setregid
+205	common	getgroups32		sys_getgroups
+206	common	setgroups32		sys_setgroups
+207	common	fchown32		sys_fchown
+208	common	setresuid32		sys_setresuid
+209	common	getresuid32		sys_getresuid
+210	common	setresgid32		sys_setresgid
+211	common	getresgid32		sys_getresgid
+212	common	chown32			sys_chown
+213	common	setuid32		sys_setuid
+214	common	setgid32		sys_setgid
+215	common	setfsuid32		sys_setfsuid
+216	common	setfsgid32		sys_setfsgid
+217	common	getdents64		sys_getdents64
+218	common	pivot_root		sys_pivot_root
+219	common	mincore			sys_mincore
+220	common	madvise			sys_madvise
+221	oabi	fcntl64			sys_fcntl64		sys_oabi_fcntl64
+221	eabi	fcntl64			sys_fcntl64
+# 222 for tux
+# 223 is unused
+224	common	gettid			sys_gettid
+225	oabi	readahead		sys_readahead		sys_oabi_readahead
+225	eabi	readahead		sys_readahead
+226	common	setxattr		sys_setxattr
+227	common	lsetxattr		sys_lsetxattr
+228	common	fsetxattr		sys_fsetxattr
+229	common	getxattr		sys_getxattr
+230	common	lgetxattr		sys_lgetxattr
+231	common	fgetxattr		sys_fgetxattr
+232	common	listxattr		sys_listxattr
+233	common	llistxattr		sys_llistxattr
+234	common	flistxattr		sys_flistxattr
+235	common	removexattr		sys_removexattr
+236	common	lremovexattr		sys_lremovexattr
+237	common	fremovexattr		sys_fremovexattr
+238	common	tkill			sys_tkill
+239	common	sendfile64		sys_sendfile64
+240	common	futex			sys_futex
+241	common	sched_setaffinity	sys_sched_setaffinity
+242	common	sched_getaffinity	sys_sched_getaffinity
+243	common	io_setup		sys_io_setup
+244	common	io_destroy		sys_io_destroy
+245	common	io_getevents		sys_io_getevents
+246	common	io_submit		sys_io_submit
+247	common	io_cancel		sys_io_cancel
+248	common	exit_group		sys_exit_group
+249	common	lookup_dcookie		sys_lookup_dcookie
+250	common	epoll_create		sys_epoll_create
+251	oabi	epoll_ctl		sys_epoll_ctl		sys_oabi_epoll_ctl
+251	eabi	epoll_ctl		sys_epoll_ctl
+252	oabi	epoll_wait		sys_epoll_wait		sys_oabi_epoll_wait
+252	eabi	epoll_wait		sys_epoll_wait
+253	common	remap_file_pages	sys_remap_file_pages
+# 254 for set_thread_area
+# 255 for get_thread_area
+256	common	set_tid_address		sys_set_tid_address
+257	common	timer_create		sys_timer_create
+258	common	timer_settime		sys_timer_settime
+259	common	timer_gettime		sys_timer_gettime
+260	common	timer_getoverrun	sys_timer_getoverrun
+261	common	timer_delete		sys_timer_delete
+262	common	clock_settime		sys_clock_settime
+263	common	clock_gettime		sys_clock_gettime
+264	common	clock_getres		sys_clock_getres
+265	common	clock_nanosleep		sys_clock_nanosleep
+266	common	statfs64		sys_statfs64_wrapper
+267	common	fstatfs64		sys_fstatfs64_wrapper
+268	common	tgkill			sys_tgkill
+269	common	utimes			sys_utimes
+270	common	arm_fadvise64_64	sys_arm_fadvise64_64
+271	common	pciconfig_iobase	sys_pciconfig_iobase
+272	common	pciconfig_read		sys_pciconfig_read
+273	common	pciconfig_write		sys_pciconfig_write
+274	common	mq_open			sys_mq_open
+275	common	mq_unlink		sys_mq_unlink
+276	common	mq_timedsend		sys_mq_timedsend
+277	common	mq_timedreceive		sys_mq_timedreceive
+278	common	mq_notify		sys_mq_notify
+279	common	mq_getsetattr		sys_mq_getsetattr
+280	common	waitid			sys_waitid
+281	common	socket			sys_socket
+282	oabi	bind			sys_bind		sys_oabi_bind
+282	eabi	bind			sys_bind
+283	oabi	connect			sys_connect		sys_oabi_connect
+283	eabi	connect			sys_connect
+284	common	listen			sys_listen
+285	common	accept			sys_accept
+286	common	getsockname		sys_getsockname
+287	common	getpeername		sys_getpeername
+288	common	socketpair		sys_socketpair
+289	common	send			sys_send
+290	oabi	sendto			sys_sendto		sys_oabi_sendto
+290	eabi	sendto			sys_sendto
+291	common	recv			sys_recv
+292	common	recvfrom		sys_recvfrom
+293	common	shutdown		sys_shutdown
+294	common	setsockopt		sys_setsockopt
+295	common	getsockopt		sys_getsockopt
+296	oabi	sendmsg			sys_sendmsg		sys_oabi_sendmsg
+296	eabi	sendmsg			sys_sendmsg
+297	common	recvmsg			sys_recvmsg
+298	oabi	semop			sys_semop		sys_oabi_semop
+298	eabi	semop			sys_semop
+299	common	semget			sys_semget
+300	common	semctl			sys_semctl
+301	common	msgsnd			sys_msgsnd
+302	common	msgrcv			sys_msgrcv
+303	common	msgget			sys_msgget
+304	common	msgctl			sys_msgctl
+305	common	shmat			sys_shmat
+306	common	shmdt			sys_shmdt
+307	common	shmget			sys_shmget
+308	common	shmctl			sys_shmctl
+309	common	add_key			sys_add_key
+310	common	request_key		sys_request_key
+311	common	keyctl			sys_keyctl
+312	oabi	semtimedop		sys_semtimedop		sys_oabi_semtimedop
+312	eabi	semtimedop		sys_semtimedop
+313	common	vserver
+314	common	ioprio_set		sys_ioprio_set
+315	common	ioprio_get		sys_ioprio_get
+316	common	inotify_init		sys_inotify_init
+317	common	inotify_add_watch	sys_inotify_add_watch
+318	common	inotify_rm_watch	sys_inotify_rm_watch
+319	common	mbind			sys_mbind
+320	common	get_mempolicy		sys_get_mempolicy
+321	common	set_mempolicy		sys_set_mempolicy
+322	common	openat			sys_openat
+323	common	mkdirat			sys_mkdirat
+324	common	mknodat			sys_mknodat
+325	common	fchownat		sys_fchownat
+326	common	futimesat		sys_futimesat
+327	oabi	fstatat64		sys_fstatat64		sys_oabi_fstatat64
+327	eabi	fstatat64		sys_fstatat64
+328	common	unlinkat		sys_unlinkat
+329	common	renameat		sys_renameat
+330	common	linkat			sys_linkat
+331	common	symlinkat		sys_symlinkat
+332	common	readlinkat		sys_readlinkat
+333	common	fchmodat		sys_fchmodat
+334	common	faccessat		sys_faccessat
+335	common	pselect6		sys_pselect6
+336	common	ppoll			sys_ppoll
+337	common	unshare			sys_unshare
+338	common	set_robust_list		sys_set_robust_list
+339	common	get_robust_list		sys_get_robust_list
+340	common	splice			sys_splice
+341	common	arm_sync_file_range	sys_sync_file_range2
+342	common	tee			sys_tee
+343	common	vmsplice		sys_vmsplice
+344	common	move_pages		sys_move_pages
+345	common	getcpu			sys_getcpu
+346	common	epoll_pwait		sys_epoll_pwait
+347	common	kexec_load		sys_kexec_load
+348	common	utimensat		sys_utimensat
+349	common	signalfd		sys_signalfd
+350	common	timerfd_create		sys_timerfd_create
+351	common	eventfd			sys_eventfd
+352	common	fallocate		sys_fallocate
+353	common	timerfd_settime		sys_timerfd_settime
+354	common	timerfd_gettime		sys_timerfd_gettime
+355	common	signalfd4		sys_signalfd4
+356	common	eventfd2		sys_eventfd2
+357	common	epoll_create1		sys_epoll_create1
+358	common	dup3			sys_dup3
+359	common	pipe2			sys_pipe2
+360	common	inotify_init1		sys_inotify_init1
+361	common	preadv			sys_preadv
+362	common	pwritev			sys_pwritev
+363	common	rt_tgsigqueueinfo	sys_rt_tgsigqueueinfo
+364	common	perf_event_open		sys_perf_event_open
+365	common	recvmmsg		sys_recvmmsg
+366	common	accept4			sys_accept4
+367	common	fanotify_init		sys_fanotify_init
+368	common	fanotify_mark		sys_fanotify_mark
+369	common	prlimit64		sys_prlimit64
+370	common	name_to_handle_at	sys_name_to_handle_at
+371	common	open_by_handle_at	sys_open_by_handle_at
+372	common	clock_adjtime		sys_clock_adjtime
+373	common	syncfs			sys_syncfs
+374	common	sendmmsg		sys_sendmmsg
+375	common	setns			sys_setns
+376	common	process_vm_readv	sys_process_vm_readv
+377	common	process_vm_writev	sys_process_vm_writev
+378	common	kcmp			sys_kcmp
+379	common	finit_module		sys_finit_module
+380	common	sched_setattr		sys_sched_setattr
+381	common	sched_getattr		sys_sched_getattr
+382	common	renameat2		sys_renameat2
+383	common	seccomp			sys_seccomp
+384	common	getrandom		sys_getrandom
+385	common	memfd_create		sys_memfd_create
+386	common	bpf			sys_bpf
+387	common	execveat		sys_execveat
+388	common	userfaultfd		sys_userfaultfd
+389	common	membarrier		sys_membarrier
+390	common	mlock2			sys_mlock2
+391	common	copy_file_range		sys_copy_file_range
+392	common	preadv2			sys_preadv2
+393	common	pwritev2		sys_pwritev2
diff --git a/arch/arm/tools/syscallhdr.sh b/arch/arm/tools/syscallhdr.sh
new file mode 100644
index 000000000000..72d4b2e3bdec
--- /dev/null
+++ b/arch/arm/tools/syscallhdr.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+in="$1"
+out="$2"
+my_abis=`echo "($3)" | tr ',' '|'`
+prefix="$4"
+offset="$5"
+
+fileguard=_ASM_ARM_`basename "$out" | sed \
+    -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
+    -e 's/[^A-Z0-9_]/_/g' -e 's/__/_/g'`
+if echo $out | grep -q uapi; then
+    fileguard="_UAPI$fileguard"
+fi
+grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
+    echo "#ifndef ${fileguard}"
+    echo "#define ${fileguard} 1"
+    echo ""
+
+    while read nr abi name entry ; do
+	if [ -z "$offset" ]; then
+	    echo "#define __NR_${prefix}${name} $nr"
+	else
+	    echo "#define __NR_${prefix}${name} ($offset + $nr)"
+        fi
+    done
+
+    echo ""
+    echo "#endif /* ${fileguard} */"
+) > "$out"
diff --git a/arch/arm/tools/syscallnr.sh b/arch/arm/tools/syscallnr.sh
new file mode 100644
index 000000000000..d2971296469a
--- /dev/null
+++ b/arch/arm/tools/syscallnr.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+in="$1"
+out="$2"
+my_abis=`echo "($3)" | tr ',' '|'`
+align=1
+
+fileguard=_ASM_ARM_`basename "$out" | sed \
+    -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
+    -e 's/[^A-Z0-9_]/_/g' -e 's/__/_/g'`
+
+grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | tail -n1 | (
+    echo "#ifndef ${fileguard}
+#define ${fileguard} 1
+
+/*
+ * This needs to be greater than __NR_last_syscall+1 in order to account
+ * for the padding in the syscall table.
+ */
+"
+
+    while read nr abi name entry; do
+        nr=$(($nr + 1))
+        while [ "$(($nr / (256 * $align) ))" -gt 0 ]; do
+            align=$(( $align * 4 ))
+        done
+        nr=$(( ($nr + $align - 1) & ~($align - 1) ))
+        echo "/* aligned to $align */"
+        echo "#define __NR_syscalls $nr"
+    done
+
+    echo ""
+    echo "#endif /* ${fileguard} */"
+) > "$out"
diff --git a/arch/arm/tools/syscalltbl.sh b/arch/arm/tools/syscalltbl.sh
new file mode 100644
index 000000000000..5ca834545ed3
--- /dev/null
+++ b/arch/arm/tools/syscalltbl.sh
@@ -0,0 +1,21 @@
+#!/bin/sh
+in="$1"
+out="$2"
+my_abis=`echo "($3)" | tr ',' '|'`
+
+grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
+    while read nr abi name entry compat; do
+        if [ "$abi" = "eabi" -a -n "$compat" ]; then
+            echo "$in: error: a compat entry for an EABI syscall ($name) makes no sense" >&2
+            exit 1
+        fi
+
+	if [ -n "$entry" ]; then
+            if [ -z "$compat" ]; then
+                echo "NATIVE($nr, $entry)"
+            else
+                echo "COMPAT($nr, $entry, $compat)"
+            fi
+        fi
+    done
+) > "$out"
-- 
2.1.0

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

* [PATCH 2/3] ARM: convert to generated system call tables
  2016-10-18 19:31 [PATCH 2/3] ARM: convert to generated system call tables Russell King
@ 2016-10-19 15:30 ` Arnd Bergmann
  2016-10-19 15:53   ` Russell King - ARM Linux
  0 siblings, 1 reply; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-19 15:30 UTC (permalink / raw)
  To: linux-arm-kernel

On Tuesday, October 18, 2016 8:31:38 PM CEST Russell King wrote:
> Convert ARM to use a similar mechanism to x86 to generate the unistd.h
> system call numbers and the various kernel system call tables.  This
> means that rather than having to edit three places (asm/unistd.h for
> the total number of system calls, uapi/asm/unistd.h for the system call
> numbers, and arch/arm/kernel/calls.S for the call table) we have only
> one place to edit, making the process much more simple.
> 
> The scripts have knowledge of the table padding requirements, so there's
> no need to worry about __NR_syscalls not fitting within the immediate
> constant field of ALU instructions anymore.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Ah, very nice!

I have some vague plans to do something like this for all architectures,
so having it done for one of the more complex examples (there are very
few architectures with more than one table) simplifies it a lot.

The next step is probably to do it for asm-generic/unistd.h, which
covers a lot of architectures, and then we can introduce a shared
table for all future additions so we only have to add the new calls
in one place, and change the scripts so they can merge two input
files into one.

> diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
> new file mode 100644
> index 000000000000..62285cbd09c0
> --- /dev/null
> +++ b/arch/arm/tools/syscall.tbl
> @@ -0,0 +1,428 @@
> +#
> +# Linux system call numbers and entry vectors
> +#
> +# The format is:
> +# <num>	<abi>	<name>			<entry point>			<oabi compat entry point>
> +#
> +# Where abi is:
> +#  common - for system calls shared between oabi and eabi
> +#  oabi   - for oabi-only system calls (may have compat)
> +#  eabi   - for eabi-only system calls

Why do we need all three? I would have guessed that these two are
sufficient to cover all cases:

arm	- one entry for eabi, optional second entry for oabi if different
oabi	- only one entry for oabi, syscall is not used on eabi

> +180	oabi	pread64			sys_pread64		sys_oabi_pread64
> +180	eabi	pread64			sys_pread64
> +181	oabi	pwrite64		sys_pwrite64		sys_oabi_pwrite64
> +181	eabi	pwrite64		sys_pwrite64

That would avoid having to list those numbers twice, which looks
a bit odd here, and is inconsistent with how x86 handles their
compat table for x32

> diff --git a/arch/arm/tools/syscallhdr.sh b/arch/arm/tools/syscallhdr.sh
> new file mode 100644
> index 000000000000..72d4b2e3bdec
> --- /dev/null
> +++ b/arch/arm/tools/syscallhdr.sh

The scripts are still very similar to the x86 version. Any chance
we can move them to a top-level scripts/syscall/ directory and make
them work for both architectures? It would be good to avoid duplicating
them for all the other architectures too, so starting out with a common
version could make that easier.

If necessary, I can do that once I get to the following stage of
doing the asm-generic/unistd.h replacement.

	Arnd

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

* [PATCH 2/3] ARM: convert to generated system call tables
  2016-10-19 15:30 ` Arnd Bergmann
@ 2016-10-19 15:53   ` Russell King - ARM Linux
  2016-10-21 13:06       ` Arnd Bergmann
  0 siblings, 1 reply; 49+ messages in thread
From: Russell King - ARM Linux @ 2016-10-19 15:53 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Oct 19, 2016 at 05:30:49PM +0200, Arnd Bergmann wrote:
> On Tuesday, October 18, 2016 8:31:38 PM CEST Russell King wrote:
> > Convert ARM to use a similar mechanism to x86 to generate the unistd.h
> > system call numbers and the various kernel system call tables.  This
> > means that rather than having to edit three places (asm/unistd.h for
> > the total number of system calls, uapi/asm/unistd.h for the system call
> > numbers, and arch/arm/kernel/calls.S for the call table) we have only
> > one place to edit, making the process much more simple.
> > 
> > The scripts have knowledge of the table padding requirements, so there's
> > no need to worry about __NR_syscalls not fitting within the immediate
> > constant field of ALU instructions anymore.
> > 
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> 
> Ah, very nice!
> 
> I have some vague plans to do something like this for all architectures,
> so having it done for one of the more complex examples (there are very
> few architectures with more than one table) simplifies it a lot.
> 
> The next step is probably to do it for asm-generic/unistd.h, which
> covers a lot of architectures, and then we can introduce a shared
> table for all future additions so we only have to add the new calls
> in one place, and change the scripts so they can merge two input
> files into one.

Architecture maintainers like to verify that the system call works on
their architecture before they push it out into the wild; your idea
effectively bypasses architecture maintainer review and testing, so
is bad.  For something as critical as system call interfaces, that
step is critical: introducing a new system call across all architectures
that then fails to work correctly on a particular architecture invites
userspace to work around the problem, and the brokenness then becomes
user API which can't be fixed.

> > +# Where abi is:
> > +#  common - for system calls shared between oabi and eabi
> > +#  oabi   - for oabi-only system calls (may have compat)
> > +#  eabi   - for eabi-only system calls
> 
> Why do we need all three? I would have guessed that these two are
> sufficient to cover all cases:
> 
> arm	- one entry for eabi, optional second entry for oabi if different
> oabi	- only one entry for oabi, syscall is not used on eabi

You haven't quite understood if you think the second entry gets used
for OABI - but that's not surprising because the issues here are
quite complex.

For OABI-only, all the oabi and first entry in common gets used.
For EABI-only, all the eabi and first entry in common gets used.
For EABI with OABI compat, EABI uses eabi and the first entry in common,
but the OABI compat table uses the oabi and common entries, prefering
the second entry where present.

Yes, for the cases where we list the oabi and eabi together like you
quoted, currently there are no differences between the system calls,
and in my latest version, they've already been modified down to just
a single "common" entry, leaving us without any eabi entries.
However, I want to retain the ability to have separate eabi entries
if needs be.  Such a case would be a system call which needs a helper
for arguments passed in >4 registers on EABI but not OABI (eg, because
of an non-naturally aligned 64-bit quantity passed in r1/r2 on OABI
but r2/r3 in EABI.)

You'll find the latest version in the next linux-next, or my current
for-next branch.

> > diff --git a/arch/arm/tools/syscallhdr.sh b/arch/arm/tools/syscallhdr.sh
> > new file mode 100644
> > index 000000000000..72d4b2e3bdec
> > --- /dev/null
> > +++ b/arch/arm/tools/syscallhdr.sh
> 
> The scripts are still very similar to the x86 version. Any chance
> we can move them to a top-level scripts/syscall/ directory and make
> them work for both architectures? It would be good to avoid duplicating
> them for all the other architectures too, so starting out with a common
> version could make that easier.

The fileguard prefix would have to be specified as an additional
argument to achieve that, but I don't see that as a big problem.

The syscalltbl.sh script is particularly architecture specific, as
our "compat" isn't the same as x86's "compat" requirements.

The syscallnr.sh script kind-of looks like a candidate, but it has
ARM arch specifics to it (knowing that the number of system calls
needs to fit within the 8-bit value plus 4-bit shift constant
representation of ARM ALU instructions.)  Maybe a generic version
without that knowledge would work, provided architectures can
override it.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
  2016-10-19 15:53   ` Russell King - ARM Linux
@ 2016-10-21 13:06       ` Arnd Bergmann
  0 siblings, 0 replies; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-21 13:06 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-arch, linux-api

On Wednesday, October 19, 2016 4:53:25 PM CEST Russell King - ARM Linux wrote:
> On Wed, Oct 19, 2016 at 05:30:49PM +0200, Arnd Bergmann wrote:
> > On Tuesday, October 18, 2016 8:31:38 PM CEST Russell King wrote:
> > > Convert ARM to use a similar mechanism to x86 to generate the unistd.h
> > > system call numbers and the various kernel system call tables.  This
> > > means that rather than having to edit three places (asm/unistd.h for
> > > the total number of system calls, uapi/asm/unistd.h for the system call
> > > numbers, and arch/arm/kernel/calls.S for the call table) we have only
> > > one place to edit, making the process much more simple.
> > > 
> > > The scripts have knowledge of the table padding requirements, so there's
> > > no need to worry about __NR_syscalls not fitting within the immediate
> > > constant field of ALU instructions anymore.
> > > 
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > 
> > Ah, very nice!
> > 
> > I have some vague plans to do something like this for all architectures,
> > so having it done for one of the more complex examples (there are very
> > few architectures with more than one table) simplifies it a lot.
> > 
> > The next step is probably to do it for asm-generic/unistd.h, which
> > covers a lot of architectures, and then we can introduce a shared
> > table for all future additions so we only have to add the new calls
> > in one place, and change the scripts so they can merge two input
> > files into one.
> 
> Architecture maintainers like to verify that the system call works on
> their architecture before they push it out into the wild; your idea
> effectively bypasses architecture maintainer review and testing, so
> is bad.  For something as critical as system call interfaces, that
> step is critical: introducing a new system call across all architectures
> that then fails to work correctly on a particular architecture invites
> userspace to work around the problem, and the brokenness then becomes
> user API which can't be fixed.

I see your point, but I think there are serious issues with the current
approach as well:

- a lot of the less common architectures just don't get updated
  in time, out of 22 architectures that don't use asm-generic/unistd.h,
  only 12 have pwritev2 in linux-next, and only three have pkey_mprotect

- some architectures that add all syscalls sometimes make a mistake
  and forget one, e.g. alpha apparently never added __NR_bpf, but it
  did add the later __NR_execveat.

- when glibc updates their minimum supported kernel version, they
  would like to drop obsolete syscalls, but when each architecture
  adds the calls at a different time, it's hard to tell when a
  replacement syscall is guaranteed to be available

- linux-next produces warnings about missing syscalls on most
  architectures half of the time since it's impossible for an
  arch maintainer to hook up the number before the implementation
  is merged 

Regarding the review process, I'd really hope we've improved enough
that we can rely on the review on linux-arch/linux-api to catch
all serious issues like system call that cannot be defined the same
way on all architectures. If we fail at this, there is a more
serious issue with the review process.

Since all syscalls now go through SYSCALL_DEFINEx(), we have
covered the hardest part (sign/zero extending short arguments),
and a lot more people are aware of problems with struct alignment
since it differs between i386 and x86_64 and also affects all
ioctl interfaces. I think the last time a syscall made it in that
didn't just work on all architectures was sync_file_range, and
that was nine years ago.

> > > +# Where abi is:
> > > +#  common - for system calls shared between oabi and eabi
> > > +#  oabi   - for oabi-only system calls (may have compat)
> > > +#  eabi   - for eabi-only system calls
> > 
> > Why do we need all three? I would have guessed that these two are
> > sufficient to cover all cases:
> > 
> > arm	- one entry for eabi, optional second entry for oabi if different
> > oabi	- only one entry for oabi, syscall is not used on eabi
> 
> You haven't quite understood if you think the second entry gets used
> for OABI - but that's not surprising because the issues here are
> quite complex.
> 
> For OABI-only, all the oabi and first entry in common gets used.
> For EABI-only, all the eabi and first entry in common gets used.
> For EABI with OABI compat, EABI uses eabi and the first entry in common,
> but the OABI compat table uses the oabi and common entries, prefering
> the second entry where present.

Got it, I missed the fact that we support native OABI kernels.

> Yes, for the cases where we list the oabi and eabi together like you
> quoted, currently there are no differences between the system calls,
> and in my latest version, they've already been modified down to just
> a single "common" entry, leaving us without any eabi entries.
>
> However, I want to retain the ability to have separate eabi entries
> if needs be.  Such a case would be a system call which needs a helper
> for arguments passed in >4 registers on EABI but not OABI (eg, because
> of an non-naturally aligned 64-bit quantity passed in r1/r2 on OABI
> but r2/r3 in EABI.)

If we hit this case, why not just use the wrapper on both EABI
and OABI for simplicity? It's not like we care a lot about
micro-optimizing OABI any more.

> You'll find the latest version in the next linux-next, or my current
> for-next branch.

Ok. After rebasing my randconfig tree on today's linux-next, I needed
this hunk to avoid a warning:

<stdin>:1143:2: error: #warning syscall sync_file_range not implemented [-Werror=cpp]

diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
index 70558e4459fd..7da1bbe69e56 100644
--- a/arch/arm/tools/syscall.tbl
+++ b/arch/arm/tools/syscall.tbl
@@ -355,7 +355,8 @@
 338	common	set_robust_list		sys_set_robust_list
 339	common	get_robust_list		sys_get_robust_list
 340	common	splice			sys_splice
-341	common	arm_sync_file_range	sys_sync_file_range2
+341	common	sync_file_range2		sys_sync_file_range2
+341	common	arm_sync_file_range
 342	common	tee			sys_tee
 343	common	vmsplice		sys_vmsplice
 344	common	move_pages		sys_move_pages

(or alternatively, add "#define sync_file_range2 arm_sync_file_range"
to uapi/asm/unistd.h).

> > > diff --git a/arch/arm/tools/syscallhdr.sh b/arch/arm/tools/syscallhdr.sh
> > > new file mode 100644
> > > index 000000000000..72d4b2e3bdec
> > > --- /dev/null
> > > +++ b/arch/arm/tools/syscallhdr.sh
> > 
> > The scripts are still very similar to the x86 version. Any chance
> > we can move them to a top-level scripts/syscall/ directory and make
> > them work for both architectures? It would be good to avoid duplicating
> > them for all the other architectures too, so starting out with a common
> > version could make that easier.
> 
> The fileguard prefix would have to be specified as an additional
> argument to achieve that, but I don't see that as a big problem.

Agreed, I saw the same thing there.

> The syscalltbl.sh script is particularly architecture specific, as
> our "compat" isn't the same as x86's "compat" requirements.

That brings up an interesting issue: it would be nice to use the
same input file for arch/arm/ and the compat mode of arch/arm64,
like x86 does. If we handle both oabi and arm64-compat in the same
file, we end up with a superset of what x86 does, and we could
use a single script again, and generate all four tables for
ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).

Another related case in asm-generic, which defines three tables:
native 32-bit, native 64-bit and compat 32-bit. This one not only
needs to have three different function pointers (e.g. sys_fcntl64,
sys_fcntl and compat_sys_fcntl64) but also different macros (e.g.
__NR_fcntl64 and __NR_fcntl).

Anything wrong with this approach:?

/* ARM */
221  oabi  fcntl64                 sys_fcntl64             sys_oabi_fcntl64
221  eabi  fcntl64                 sys_fcntl64             compat_sys_fcntl64

/* asm-generic */
25   32    fcntl64                 sys_fcntl64             compat_sys_fcntl64
25   64    fcntl                   sys_fcntl

> The syscallnr.sh script kind-of looks like a candidate, but it has
> ARM arch specifics to it (knowing that the number of system calls
> needs to fit within the 8-bit value plus 4-bit shift constant
> representation of ARM ALU instructions.)  Maybe a generic version
> without that knowledge would work, provided architectures can
> override it.

syscallnr.sh isn't used on x86, and probably won't be needed on
most (or all) others, right? 

Generally speaking I'd think that having a check for the ${ARCH}
variable and doing this conditionally in that one script is fine
here, if we need other architecture specific versions, they we can
use case/esac.

Similar checks exist in scripts/recordmcount.pl,
scripts/package/builddeb, scripts/tags.sh etc.

	Arnd

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 13:06       ` Arnd Bergmann
  0 siblings, 0 replies; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-21 13:06 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday, October 19, 2016 4:53:25 PM CEST Russell King - ARM Linux wrote:
> On Wed, Oct 19, 2016 at 05:30:49PM +0200, Arnd Bergmann wrote:
> > On Tuesday, October 18, 2016 8:31:38 PM CEST Russell King wrote:
> > > Convert ARM to use a similar mechanism to x86 to generate the unistd.h
> > > system call numbers and the various kernel system call tables.  This
> > > means that rather than having to edit three places (asm/unistd.h for
> > > the total number of system calls, uapi/asm/unistd.h for the system call
> > > numbers, and arch/arm/kernel/calls.S for the call table) we have only
> > > one place to edit, making the process much more simple.
> > > 
> > > The scripts have knowledge of the table padding requirements, so there's
> > > no need to worry about __NR_syscalls not fitting within the immediate
> > > constant field of ALU instructions anymore.
> > > 
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > 
> > Ah, very nice!
> > 
> > I have some vague plans to do something like this for all architectures,
> > so having it done for one of the more complex examples (there are very
> > few architectures with more than one table) simplifies it a lot.
> > 
> > The next step is probably to do it for asm-generic/unistd.h, which
> > covers a lot of architectures, and then we can introduce a shared
> > table for all future additions so we only have to add the new calls
> > in one place, and change the scripts so they can merge two input
> > files into one.
> 
> Architecture maintainers like to verify that the system call works on
> their architecture before they push it out into the wild; your idea
> effectively bypasses architecture maintainer review and testing, so
> is bad.  For something as critical as system call interfaces, that
> step is critical: introducing a new system call across all architectures
> that then fails to work correctly on a particular architecture invites
> userspace to work around the problem, and the brokenness then becomes
> user API which can't be fixed.

I see your point, but I think there are serious issues with the current
approach as well:

- a lot of the less common architectures just don't get updated
  in time, out of 22 architectures that don't use asm-generic/unistd.h,
  only 12 have pwritev2 in linux-next, and only three have pkey_mprotect

- some architectures that add all syscalls sometimes make a mistake
  and forget one, e.g. alpha apparently never added __NR_bpf, but it
  did add the later __NR_execveat.

- when glibc updates their minimum supported kernel version, they
  would like to drop obsolete syscalls, but when each architecture
  adds the calls at a different time, it's hard to tell when a
  replacement syscall is guaranteed to be available

- linux-next produces warnings about missing syscalls on most
  architectures half of the time since it's impossible for an
  arch maintainer to hook up the number before the implementation
  is merged 

Regarding the review process, I'd really hope we've improved enough
that we can rely on the review on linux-arch/linux-api to catch
all serious issues like system call that cannot be defined the same
way on all architectures. If we fail at this, there is a more
serious issue with the review process.

Since all syscalls now go through SYSCALL_DEFINEx(), we have
covered the hardest part (sign/zero extending short arguments),
and a lot more people are aware of problems with struct alignment
since it differs between i386 and x86_64 and also affects all
ioctl interfaces. I think the last time a syscall made it in that
didn't just work on all architectures was sync_file_range, and
that was nine years ago.

> > > +# Where abi is:
> > > +#  common - for system calls shared between oabi and eabi
> > > +#  oabi   - for oabi-only system calls (may have compat)
> > > +#  eabi   - for eabi-only system calls
> > 
> > Why do we need all three? I would have guessed that these two are
> > sufficient to cover all cases:
> > 
> > arm	- one entry for eabi, optional second entry for oabi if different
> > oabi	- only one entry for oabi, syscall is not used on eabi
> 
> You haven't quite understood if you think the second entry gets used
> for OABI - but that's not surprising because the issues here are
> quite complex.
> 
> For OABI-only, all the oabi and first entry in common gets used.
> For EABI-only, all the eabi and first entry in common gets used.
> For EABI with OABI compat, EABI uses eabi and the first entry in common,
> but the OABI compat table uses the oabi and common entries, prefering
> the second entry where present.

Got it, I missed the fact that we support native OABI kernels.

> Yes, for the cases where we list the oabi and eabi together like you
> quoted, currently there are no differences between the system calls,
> and in my latest version, they've already been modified down to just
> a single "common" entry, leaving us without any eabi entries.
>
> However, I want to retain the ability to have separate eabi entries
> if needs be.  Such a case would be a system call which needs a helper
> for arguments passed in >4 registers on EABI but not OABI (eg, because
> of an non-naturally aligned 64-bit quantity passed in r1/r2 on OABI
> but r2/r3 in EABI.)

If we hit this case, why not just use the wrapper on both EABI
and OABI for simplicity? It's not like we care a lot about
micro-optimizing OABI any more.

> You'll find the latest version in the next linux-next, or my current
> for-next branch.

Ok. After rebasing my randconfig tree on today's linux-next, I needed
this hunk to avoid a warning:

<stdin>:1143:2: error: #warning syscall sync_file_range not implemented [-Werror=cpp]

diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
index 70558e4459fd..7da1bbe69e56 100644
--- a/arch/arm/tools/syscall.tbl
+++ b/arch/arm/tools/syscall.tbl
@@ -355,7 +355,8 @@
 338	common	set_robust_list		sys_set_robust_list
 339	common	get_robust_list		sys_get_robust_list
 340	common	splice			sys_splice
-341	common	arm_sync_file_range	sys_sync_file_range2
+341	common	sync_file_range2		sys_sync_file_range2
+341	common	arm_sync_file_range
 342	common	tee			sys_tee
 343	common	vmsplice		sys_vmsplice
 344	common	move_pages		sys_move_pages

(or alternatively, add "#define sync_file_range2 arm_sync_file_range"
to uapi/asm/unistd.h).

> > > diff --git a/arch/arm/tools/syscallhdr.sh b/arch/arm/tools/syscallhdr.sh
> > > new file mode 100644
> > > index 000000000000..72d4b2e3bdec
> > > --- /dev/null
> > > +++ b/arch/arm/tools/syscallhdr.sh
> > 
> > The scripts are still very similar to the x86 version. Any chance
> > we can move them to a top-level scripts/syscall/ directory and make
> > them work for both architectures? It would be good to avoid duplicating
> > them for all the other architectures too, so starting out with a common
> > version could make that easier.
> 
> The fileguard prefix would have to be specified as an additional
> argument to achieve that, but I don't see that as a big problem.

Agreed, I saw the same thing there.

> The syscalltbl.sh script is particularly architecture specific, as
> our "compat" isn't the same as x86's "compat" requirements.

That brings up an interesting issue: it would be nice to use the
same input file for arch/arm/ and the compat mode of arch/arm64,
like x86 does. If we handle both oabi and arm64-compat in the same
file, we end up with a superset of what x86 does, and we could
use a single script again, and generate all four tables for
ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).

Another related case in asm-generic, which defines three tables:
native 32-bit, native 64-bit and compat 32-bit. This one not only
needs to have three different function pointers (e.g. sys_fcntl64,
sys_fcntl and compat_sys_fcntl64) but also different macros (e.g.
__NR_fcntl64 and __NR_fcntl).

Anything wrong with this approach:?

/* ARM */
221  oabi  fcntl64                 sys_fcntl64             sys_oabi_fcntl64
221  eabi  fcntl64                 sys_fcntl64             compat_sys_fcntl64

/* asm-generic */
25   32    fcntl64                 sys_fcntl64             compat_sys_fcntl64
25   64    fcntl                   sys_fcntl

> The syscallnr.sh script kind-of looks like a candidate, but it has
> ARM arch specifics to it (knowing that the number of system calls
> needs to fit within the 8-bit value plus 4-bit shift constant
> representation of ARM ALU instructions.)  Maybe a generic version
> without that knowledge would work, provided architectures can
> override it.

syscallnr.sh isn't used on x86, and probably won't be needed on
most (or all) others, right? 

Generally speaking I'd think that having a check for the ${ARCH}
variable and doing this conditionally in that one script is fine
here, if we need other architecture specific versions, they we can
use case/esac.

Similar checks exist in scripts/recordmcount.pl,
scripts/package/builddeb, scripts/tags.sh etc.

	Arnd

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 13:37         ` Russell King - ARM Linux
  0 siblings, 0 replies; 49+ messages in thread
From: Russell King - ARM Linux @ 2016-10-21 13:37 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arch, linux-api

On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> Regarding the review process, I'd really hope we've improved enough
> that we can rely on the review on linux-arch/linux-api to catch
> all serious issues like system call that cannot be defined the same
> way on all architectures. If we fail at this, there is a more
> serious issue with the review process.

Well, forget linux-arch, that's hopeless because that became a very
x86-centric linux-kernel-v2, and as such I refuse to subscribe to it -
it would be a total waste of my network bandwidth because I wouldn't
have time to read it.

I somehow suspect that linux-api isn't that much better either.  What
I want from any "arch" specific thing is a heads-up to alert me to
something so that I can then choose whether to look deeper at the
subject or just ignore it completely.  I don't want to be buried under
lots of x86 specific drivel about a new feature.

So, the reality is, that I don't see any of the new syscall discussions
anymore.  The first that I'm aware of them is when they hit in some way
that becomes visible to me - which is normally sometime during the merge
window.

> Since all syscalls now go through SYSCALL_DEFINEx(), we have
> covered the hardest part (sign/zero extending short arguments),
> and a lot more people are aware of problems with struct alignment
> since it differs between i386 and x86_64 and also affects all
> ioctl interfaces. I think the last time a syscall made it in that
> didn't just work on all architectures was sync_file_range, and
> that was nine years ago.

It's not really about struct alignment, although that is a concern.
For ARM, it's more about argument alignment, and whether a 64-bit
argument gets passed in (eg) r1/r2 or r2/r3, and whether we run out
of registers to pass the arguments.

> If we hit this case, why not just use the wrapper on both EABI
> and OABI for simplicity? It's not like we care a lot about
> micro-optimizing OABI any more.

I'd still like to retain the ability to only add to EABI in the future.

> > You'll find the latest version in the next linux-next, or my current
> > for-next branch.
> 
> Ok. After rebasing my randconfig tree on today's linux-next, I needed
> this hunk to avoid a warning:
> 
> <stdin>:1143:2: error: #warning syscall sync_file_range not implemented [-Werror=cpp]

I don't get that on my builds, for EABI or OABI - for EABI:

  CHK     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  CALL    /home/rmk/git/linux-rmk/scripts/checksyscalls.sh
make[1]: Leaving directory '/home/rmk/git/build/hdrtst'

and for OABI:

  CHK     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  CALL    /home/rmk/git/linux-rmk/scripts/checksyscalls.sh
make[1]: Leaving directory '/home/rmk/git/build/hdrtst-oabi'

So, I'd like to know how you're seeing that warning.  We have never
provided sync_file_range on ARM, and we must never define it, because
the user API for it is broken.

> diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
> index 70558e4459fd..7da1bbe69e56 100644
> --- a/arch/arm/tools/syscall.tbl
> +++ b/arch/arm/tools/syscall.tbl
> @@ -355,7 +355,8 @@
>  338	common	set_robust_list		sys_set_robust_list
>  339	common	get_robust_list		sys_get_robust_list
>  340	common	splice			sys_splice
> -341	common	arm_sync_file_range	sys_sync_file_range2
> +341	common	sync_file_range2		sys_sync_file_range2
> +341	common	arm_sync_file_range
>  342	common	tee			sys_tee
>  343	common	vmsplice		sys_vmsplice
>  344	common	move_pages		sys_move_pages
> 
> (or alternatively, add "#define sync_file_range2 arm_sync_file_range"
> to uapi/asm/unistd.h).

Well, I think you have a mis-merge somewhere, beacuse uapi/asm/unistd.h
does have:

#define __NR_sync_file_range2           __NR_arm_sync_file_range

in it, which triggers this in scripts/checksyscalls.sh:

/* sync_file_range had a stupid ABI. Allow sync_file_range2 instead */
#ifdef __NR_sync_file_range2
#define __IGNORE_sync_file_range
#endif

Hence why I don't see the warning you're seeing.

> That brings up an interesting issue: it would be nice to use the
> same input file for arch/arm/ and the compat mode of arch/arm64,
> like x86 does. If we handle both oabi and arm64-compat in the same
> file, we end up with a superset of what x86 does, and we could
> use a single script again, and generate all four tables for
> ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).

OABI-compat != ARM64-EABI-compat though.  They're two completely
different things.

Moreover, the syscall numbers ARM64 uses natively are completely
different from the syscall numbers 32-bit ARM uses, either for EABI
or OABI.  So I really don't see this working.

I've no idea how ARM64 deals with 32-bit binaries, so I can't comment
on how it deals with those syscalls, sorry.

> Another related case in asm-generic, which defines three tables:
> native 32-bit, native 64-bit and compat 32-bit. This one not only
> needs to have three different function pointers (e.g. sys_fcntl64,
> sys_fcntl and compat_sys_fcntl64) but also different macros (e.g.
> __NR_fcntl64 and __NR_fcntl).
> 
> Anything wrong with this approach:?
> 
> /* ARM */
> 221  oabi  fcntl64                 sys_fcntl64             sys_oabi_fcntl64
> 221  eabi  fcntl64                 sys_fcntl64             compat_sys_fcntl64
> 
> /* asm-generic */
> 25   32    fcntl64                 sys_fcntl64             compat_sys_fcntl64
> 25   64    fcntl                   sys_fcntl

Don't know, sorry.  I know virtually nothing about the differences
between the 64-bit and 32-bit ABIs, so I can't comment on anything
to do with the compat_* interfaces.

> > The syscallnr.sh script kind-of looks like a candidate, but it has
> > ARM arch specifics to it (knowing that the number of system calls
> > needs to fit within the 8-bit value plus 4-bit shift constant
> > representation of ARM ALU instructions.)  Maybe a generic version
> > without that knowledge would work, provided architectures can
> > override it.
> 
> syscallnr.sh isn't used on x86, and probably won't be needed on
> most (or all) others, right? 

Why not - the point of syscallnr.sh is to remove the need to manually
update the __NR_syscalls definition, which is a generic kernel thing.
Unless other architectures just define a fixed-size table with plenty
of extra space, they'd need to adjust __NR_syscalls when adding new
calls.


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 13:37         ` Russell King - ARM Linux
  0 siblings, 0 replies; 49+ messages in thread
From: Russell King - ARM Linux @ 2016-10-21 13:37 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-arch, linux-api

On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> Regarding the review process, I'd really hope we've improved enough
> that we can rely on the review on linux-arch/linux-api to catch
> all serious issues like system call that cannot be defined the same
> way on all architectures. If we fail at this, there is a more
> serious issue with the review process.

Well, forget linux-arch, that's hopeless because that became a very
x86-centric linux-kernel-v2, and as such I refuse to subscribe to it -
it would be a total waste of my network bandwidth because I wouldn't
have time to read it.

I somehow suspect that linux-api isn't that much better either.  What
I want from any "arch" specific thing is a heads-up to alert me to
something so that I can then choose whether to look deeper at the
subject or just ignore it completely.  I don't want to be buried under
lots of x86 specific drivel about a new feature.

So, the reality is, that I don't see any of the new syscall discussions
anymore.  The first that I'm aware of them is when they hit in some way
that becomes visible to me - which is normally sometime during the merge
window.

> Since all syscalls now go through SYSCALL_DEFINEx(), we have
> covered the hardest part (sign/zero extending short arguments),
> and a lot more people are aware of problems with struct alignment
> since it differs between i386 and x86_64 and also affects all
> ioctl interfaces. I think the last time a syscall made it in that
> didn't just work on all architectures was sync_file_range, and
> that was nine years ago.

It's not really about struct alignment, although that is a concern.
For ARM, it's more about argument alignment, and whether a 64-bit
argument gets passed in (eg) r1/r2 or r2/r3, and whether we run out
of registers to pass the arguments.

> If we hit this case, why not just use the wrapper on both EABI
> and OABI for simplicity? It's not like we care a lot about
> micro-optimizing OABI any more.

I'd still like to retain the ability to only add to EABI in the future.

> > You'll find the latest version in the next linux-next, or my current
> > for-next branch.
> 
> Ok. After rebasing my randconfig tree on today's linux-next, I needed
> this hunk to avoid a warning:
> 
> <stdin>:1143:2: error: #warning syscall sync_file_range not implemented [-Werror=cpp]

I don't get that on my builds, for EABI or OABI - for EABI:

  CHK     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  CALL    /home/rmk/git/linux-rmk/scripts/checksyscalls.sh
make[1]: Leaving directory '/home/rmk/git/build/hdrtst'

and for OABI:

  CHK     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  CALL    /home/rmk/git/linux-rmk/scripts/checksyscalls.sh
make[1]: Leaving directory '/home/rmk/git/build/hdrtst-oabi'

So, I'd like to know how you're seeing that warning.  We have never
provided sync_file_range on ARM, and we must never define it, because
the user API for it is broken.

> diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
> index 70558e4459fd..7da1bbe69e56 100644
> --- a/arch/arm/tools/syscall.tbl
> +++ b/arch/arm/tools/syscall.tbl
> @@ -355,7 +355,8 @@
>  338	common	set_robust_list		sys_set_robust_list
>  339	common	get_robust_list		sys_get_robust_list
>  340	common	splice			sys_splice
> -341	common	arm_sync_file_range	sys_sync_file_range2
> +341	common	sync_file_range2		sys_sync_file_range2
> +341	common	arm_sync_file_range
>  342	common	tee			sys_tee
>  343	common	vmsplice		sys_vmsplice
>  344	common	move_pages		sys_move_pages
> 
> (or alternatively, add "#define sync_file_range2 arm_sync_file_range"
> to uapi/asm/unistd.h).

Well, I think you have a mis-merge somewhere, beacuse uapi/asm/unistd.h
does have:

#define __NR_sync_file_range2           __NR_arm_sync_file_range

in it, which triggers this in scripts/checksyscalls.sh:

/* sync_file_range had a stupid ABI. Allow sync_file_range2 instead */
#ifdef __NR_sync_file_range2
#define __IGNORE_sync_file_range
#endif

Hence why I don't see the warning you're seeing.

> That brings up an interesting issue: it would be nice to use the
> same input file for arch/arm/ and the compat mode of arch/arm64,
> like x86 does. If we handle both oabi and arm64-compat in the same
> file, we end up with a superset of what x86 does, and we could
> use a single script again, and generate all four tables for
> ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).

OABI-compat != ARM64-EABI-compat though.  They're two completely
different things.

Moreover, the syscall numbers ARM64 uses natively are completely
different from the syscall numbers 32-bit ARM uses, either for EABI
or OABI.  So I really don't see this working.

I've no idea how ARM64 deals with 32-bit binaries, so I can't comment
on how it deals with those syscalls, sorry.

> Another related case in asm-generic, which defines three tables:
> native 32-bit, native 64-bit and compat 32-bit. This one not only
> needs to have three different function pointers (e.g. sys_fcntl64,
> sys_fcntl and compat_sys_fcntl64) but also different macros (e.g.
> __NR_fcntl64 and __NR_fcntl).
> 
> Anything wrong with this approach:?
> 
> /* ARM */
> 221  oabi  fcntl64                 sys_fcntl64             sys_oabi_fcntl64
> 221  eabi  fcntl64                 sys_fcntl64             compat_sys_fcntl64
> 
> /* asm-generic */
> 25   32    fcntl64                 sys_fcntl64             compat_sys_fcntl64
> 25   64    fcntl                   sys_fcntl

Don't know, sorry.  I know virtually nothing about the differences
between the 64-bit and 32-bit ABIs, so I can't comment on anything
to do with the compat_* interfaces.

> > The syscallnr.sh script kind-of looks like a candidate, but it has
> > ARM arch specifics to it (knowing that the number of system calls
> > needs to fit within the 8-bit value plus 4-bit shift constant
> > representation of ARM ALU instructions.)  Maybe a generic version
> > without that knowledge would work, provided architectures can
> > override it.
> 
> syscallnr.sh isn't used on x86, and probably won't be needed on
> most (or all) others, right? 

Why not - the point of syscallnr.sh is to remove the need to manually
update the __NR_syscalls definition, which is a generic kernel thing.
Unless other architectures just define a fixed-size table with plenty
of extra space, they'd need to adjust __NR_syscalls when adding new
calls.


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 13:37         ` Russell King - ARM Linux
  0 siblings, 0 replies; 49+ messages in thread
From: Russell King - ARM Linux @ 2016-10-21 13:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> Regarding the review process, I'd really hope we've improved enough
> that we can rely on the review on linux-arch/linux-api to catch
> all serious issues like system call that cannot be defined the same
> way on all architectures. If we fail at this, there is a more
> serious issue with the review process.

Well, forget linux-arch, that's hopeless because that became a very
x86-centric linux-kernel-v2, and as such I refuse to subscribe to it -
it would be a total waste of my network bandwidth because I wouldn't
have time to read it.

I somehow suspect that linux-api isn't that much better either.  What
I want from any "arch" specific thing is a heads-up to alert me to
something so that I can then choose whether to look deeper at the
subject or just ignore it completely.  I don't want to be buried under
lots of x86 specific drivel about a new feature.

So, the reality is, that I don't see any of the new syscall discussions
anymore.  The first that I'm aware of them is when they hit in some way
that becomes visible to me - which is normally sometime during the merge
window.

> Since all syscalls now go through SYSCALL_DEFINEx(), we have
> covered the hardest part (sign/zero extending short arguments),
> and a lot more people are aware of problems with struct alignment
> since it differs between i386 and x86_64 and also affects all
> ioctl interfaces. I think the last time a syscall made it in that
> didn't just work on all architectures was sync_file_range, and
> that was nine years ago.

It's not really about struct alignment, although that is a concern.
For ARM, it's more about argument alignment, and whether a 64-bit
argument gets passed in (eg) r1/r2 or r2/r3, and whether we run out
of registers to pass the arguments.

> If we hit this case, why not just use the wrapper on both EABI
> and OABI for simplicity? It's not like we care a lot about
> micro-optimizing OABI any more.

I'd still like to retain the ability to only add to EABI in the future.

> > You'll find the latest version in the next linux-next, or my current
> > for-next branch.
> 
> Ok. After rebasing my randconfig tree on today's linux-next, I needed
> this hunk to avoid a warning:
> 
> <stdin>:1143:2: error: #warning syscall sync_file_range not implemented [-Werror=cpp]

I don't get that on my builds, for EABI or OABI - for EABI:

  CHK     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  CALL    /home/rmk/git/linux-rmk/scripts/checksyscalls.sh
make[1]: Leaving directory '/home/rmk/git/build/hdrtst'

and for OABI:

  CHK     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  CALL    /home/rmk/git/linux-rmk/scripts/checksyscalls.sh
make[1]: Leaving directory '/home/rmk/git/build/hdrtst-oabi'

So, I'd like to know how you're seeing that warning.  We have never
provided sync_file_range on ARM, and we must never define it, because
the user API for it is broken.

> diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
> index 70558e4459fd..7da1bbe69e56 100644
> --- a/arch/arm/tools/syscall.tbl
> +++ b/arch/arm/tools/syscall.tbl
> @@ -355,7 +355,8 @@
>  338	common	set_robust_list		sys_set_robust_list
>  339	common	get_robust_list		sys_get_robust_list
>  340	common	splice			sys_splice
> -341	common	arm_sync_file_range	sys_sync_file_range2
> +341	common	sync_file_range2		sys_sync_file_range2
> +341	common	arm_sync_file_range
>  342	common	tee			sys_tee
>  343	common	vmsplice		sys_vmsplice
>  344	common	move_pages		sys_move_pages
> 
> (or alternatively, add "#define sync_file_range2 arm_sync_file_range"
> to uapi/asm/unistd.h).

Well, I think you have a mis-merge somewhere, beacuse uapi/asm/unistd.h
does have:

#define __NR_sync_file_range2           __NR_arm_sync_file_range

in it, which triggers this in scripts/checksyscalls.sh:

/* sync_file_range had a stupid ABI. Allow sync_file_range2 instead */
#ifdef __NR_sync_file_range2
#define __IGNORE_sync_file_range
#endif

Hence why I don't see the warning you're seeing.

> That brings up an interesting issue: it would be nice to use the
> same input file for arch/arm/ and the compat mode of arch/arm64,
> like x86 does. If we handle both oabi and arm64-compat in the same
> file, we end up with a superset of what x86 does, and we could
> use a single script again, and generate all four tables for
> ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).

OABI-compat != ARM64-EABI-compat though.  They're two completely
different things.

Moreover, the syscall numbers ARM64 uses natively are completely
different from the syscall numbers 32-bit ARM uses, either for EABI
or OABI.  So I really don't see this working.

I've no idea how ARM64 deals with 32-bit binaries, so I can't comment
on how it deals with those syscalls, sorry.

> Another related case in asm-generic, which defines three tables:
> native 32-bit, native 64-bit and compat 32-bit. This one not only
> needs to have three different function pointers (e.g. sys_fcntl64,
> sys_fcntl and compat_sys_fcntl64) but also different macros (e.g.
> __NR_fcntl64 and __NR_fcntl).
> 
> Anything wrong with this approach:?
> 
> /* ARM */
> 221  oabi  fcntl64                 sys_fcntl64             sys_oabi_fcntl64
> 221  eabi  fcntl64                 sys_fcntl64             compat_sys_fcntl64
> 
> /* asm-generic */
> 25   32    fcntl64                 sys_fcntl64             compat_sys_fcntl64
> 25   64    fcntl                   sys_fcntl

Don't know, sorry.  I know virtually nothing about the differences
between the 64-bit and 32-bit ABIs, so I can't comment on anything
to do with the compat_* interfaces.

> > The syscallnr.sh script kind-of looks like a candidate, but it has
> > ARM arch specifics to it (knowing that the number of system calls
> > needs to fit within the 8-bit value plus 4-bit shift constant
> > representation of ARM ALU instructions.)  Maybe a generic version
> > without that knowledge would work, provided architectures can
> > override it.
> 
> syscallnr.sh isn't used on x86, and probably won't be needed on
> most (or all) others, right? 

Why not - the point of syscallnr.sh is to remove the need to manually
update the __NR_syscalls definition, which is a generic kernel thing.
Unless other architectures just define a fixed-size table with plenty
of extra space, they'd need to adjust __NR_syscalls when adding new
calls.


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 15:18             ` Arnd Bergmann
  0 siblings, 0 replies; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-21 15:18 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
  Cc: Russell King - ARM Linux, linux-arch, linux-api

On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:

> > If we hit this case, why not just use the wrapper on both EABI
> > and OABI for simplicity? It's not like we care a lot about
> > micro-optimizing OABI any more.
> 
> I'd still like to retain the ability to only add to EABI in the future.

Do you mean to add an EABI specific workaround for a specific syscall
if necessary, or to stop adding OABI syscalls altogether?

For the first one, the way that the asm-generic unistd.h handles this is
to have a range of syscall numbers reserved for architecture specific
additions. I was planning to do the same here and have a number of
reserved numbers after the last architecture specific call before
the start of the newly added generic numbers.

> > (or alternatively, add "#define sync_file_range2 arm_sync_file_range"
> > to uapi/asm/unistd.h).
> 
> Well, I think you have a mis-merge somewhere, beacuse uapi/asm/unistd.h
> does have:
> 
> #define __NR_sync_file_range2           __NR_arm_sync_file_range
> 
> in it, which triggers this in scripts/checksyscalls.sh:

That was it, I had merged in my y2038 syscall series for testing and
accidentally dropped that line while rebasing the newly added
syscalls.

> > That brings up an interesting issue: it would be nice to use the
> > same input file for arch/arm/ and the compat mode of arch/arm64,
> > like x86 does. If we handle both oabi and arm64-compat in the same
> > file, we end up with a superset of what x86 does, and we could
> > use a single script again, and generate all four tables for
> > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> 
> OABI-compat != ARM64-EABI-compat though.  They're two completely
> different things.

For the purpose of generating the tables, I don't see much
difference: we either use the fourth column only in native
mode, or we use the fifth column to override values from
the fourth one when emulating the ABI on the "other" kernel.

> Moreover, the syscall numbers ARM64 uses natively are completely
> different from the syscall numbers 32-bit ARM uses, either for EABI
> or OABI.  So I really don't see this working.

That's similar to x86, 32-bit syscalls use the traditional numbers
with an optionally different entry point for compat mode, while
64-bit syscalls use a somewhat reduced table that now has support
for both native 64-bit and "x32" mode. x86-64 and x32 share a
syscall table but not the unistd.h list, all three generated
from syscall_64.tbl.

> I've no idea how ARM64 deals with 32-bit binaries, so I can't comment
> on how it deals with those syscalls, sorry.

ARM64 has a separate list of syscalls for compat mode in 
arch/arm64/include/asm/unistd32.h, this list has the same format
as include/asm-generic/uapi/unistd.h and must be updated manually
to match the arch/arm/ table today.

ARM64 will also likely gain native (A64 instruction set) ILP32
support soon, which will use the same numbers as the 64-bit
mode but point to the compat syscalls. This is similar to
how ARM OABI emulation works.

> > Another related case in asm-generic, which defines three tables:
> > native 32-bit, native 64-bit and compat 32-bit. This one not only
> > needs to have three different function pointers (e.g. sys_fcntl64,
> > sys_fcntl and compat_sys_fcntl64) but also different macros (e.g.
> > __NR_fcntl64 and __NR_fcntl).
> > 
> > Anything wrong with this approach:?
> > 
> > /* ARM */
> > 221  oabi  fcntl64                 sys_fcntl64             sys_oabi_fcntl64
> > 221  eabi  fcntl64                 sys_fcntl64             compat_sys_fcntl64
> > 
> > /* asm-generic */
> > 25   32    fcntl64                 sys_fcntl64             compat_sys_fcntl64
> > 25   64    fcntl                   sys_fcntl
> 
> Don't know, sorry.  I know virtually nothing about the differences
> between the 64-bit and 32-bit ABIs, so I can't comment on anything
> to do with the compat_* interfaces.

The only important factor here is that the first three columns are used
to generate unistd.h, which is the same for both native and emulated
mode, while the last two columns are used to generate two sets of
syscall tables using the same numbers. This is a common requirement
for OABI mode (native or emulated), EABI (on 32-bit or 64-bit kernels)
and the generic ABI (native 32-bit or emulated 32-bit). 

The 64-bit unistd.h is differs only in those syscalls that got replaced
with when loff_t support was added:

#define __NR_fcntl __NR3264_fcntl
#define __NR_statfs __NR3264_statfs
#define __NR_fstatfs __NR3264_fstatfs
#define __NR_truncate __NR3264_truncate
#define __NR_ftruncate __NR3264_ftruncate
#define __NR_lseek __NR3264_lseek
#define __NR_sendfile __NR3264_sendfile
#define __NR_newfstatat __NR3264_fstatat
#define __NR_fstat __NR3264_fstat
#define __NR_mmap __NR3264_mmap
#define __NR_fadvise64 __NR3264_fadvise64
#define __NR_stat __NR3264_stat
#define __NR_lstat __NR3264_lstat

64-bit architectures still use __NR_fcntl, while 32-bit architectures
use __NR_fcntl64 etc.

> > > The syscallnr.sh script kind-of looks like a candidate, but it has
> > > ARM arch specifics to it (knowing that the number of system calls
> > > needs to fit within the 8-bit value plus 4-bit shift constant
> > > representation of ARM ALU instructions.)  Maybe a generic version
> > > without that knowledge would work, provided architectures can
> > > override it.
> > 
> > syscallnr.sh isn't used on x86, and probably won't be needed on
> > most (or all) others, right? 
> 
> Why not - the point of syscallnr.sh is to remove the need to manually
> update the __NR_syscalls definition, which is a generic kernel thing.
> Unless other architectures just define a fixed-size table with plenty
> of extra space, they'd need to adjust __NR_syscalls when adding new
> calls.

Ah, makes sense. I see that x86 does this in
arch/x86/kernel/asm-offsets_64.c in a way that would also work on
other architectures, but being able to share a single script across
all architectures would also help avoid duplicating that code.

	Arnd

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 15:18             ` Arnd Bergmann
  0 siblings, 0 replies; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-21 15:18 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Russell King - ARM Linux, linux-arch, linux-api

On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:

> > If we hit this case, why not just use the wrapper on both EABI
> > and OABI for simplicity? It's not like we care a lot about
> > micro-optimizing OABI any more.
> 
> I'd still like to retain the ability to only add to EABI in the future.

Do you mean to add an EABI specific workaround for a specific syscall
if necessary, or to stop adding OABI syscalls altogether?

For the first one, the way that the asm-generic unistd.h handles this is
to have a range of syscall numbers reserved for architecture specific
additions. I was planning to do the same here and have a number of
reserved numbers after the last architecture specific call before
the start of the newly added generic numbers.

> > (or alternatively, add "#define sync_file_range2 arm_sync_file_range"
> > to uapi/asm/unistd.h).
> 
> Well, I think you have a mis-merge somewhere, beacuse uapi/asm/unistd.h
> does have:
> 
> #define __NR_sync_file_range2           __NR_arm_sync_file_range
> 
> in it, which triggers this in scripts/checksyscalls.sh:

That was it, I had merged in my y2038 syscall series for testing and
accidentally dropped that line while rebasing the newly added
syscalls.

> > That brings up an interesting issue: it would be nice to use the
> > same input file for arch/arm/ and the compat mode of arch/arm64,
> > like x86 does. If we handle both oabi and arm64-compat in the same
> > file, we end up with a superset of what x86 does, and we could
> > use a single script again, and generate all four tables for
> > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> 
> OABI-compat != ARM64-EABI-compat though.  They're two completely
> different things.

For the purpose of generating the tables, I don't see much
difference: we either use the fourth column only in native
mode, or we use the fifth column to override values from
the fourth one when emulating the ABI on the "other" kernel.

> Moreover, the syscall numbers ARM64 uses natively are completely
> different from the syscall numbers 32-bit ARM uses, either for EABI
> or OABI.  So I really don't see this working.

That's similar to x86, 32-bit syscalls use the traditional numbers
with an optionally different entry point for compat mode, while
64-bit syscalls use a somewhat reduced table that now has support
for both native 64-bit and "x32" mode. x86-64 and x32 share a
syscall table but not the unistd.h list, all three generated
from syscall_64.tbl.

> I've no idea how ARM64 deals with 32-bit binaries, so I can't comment
> on how it deals with those syscalls, sorry.

ARM64 has a separate list of syscalls for compat mode in 
arch/arm64/include/asm/unistd32.h, this list has the same format
as include/asm-generic/uapi/unistd.h and must be updated manually
to match the arch/arm/ table today.

ARM64 will also likely gain native (A64 instruction set) ILP32
support soon, which will use the same numbers as the 64-bit
mode but point to the compat syscalls. This is similar to
how ARM OABI emulation works.

> > Another related case in asm-generic, which defines three tables:
> > native 32-bit, native 64-bit and compat 32-bit. This one not only
> > needs to have three different function pointers (e.g. sys_fcntl64,
> > sys_fcntl and compat_sys_fcntl64) but also different macros (e.g.
> > __NR_fcntl64 and __NR_fcntl).
> > 
> > Anything wrong with this approach:?
> > 
> > /* ARM */
> > 221  oabi  fcntl64                 sys_fcntl64             sys_oabi_fcntl64
> > 221  eabi  fcntl64                 sys_fcntl64             compat_sys_fcntl64
> > 
> > /* asm-generic */
> > 25   32    fcntl64                 sys_fcntl64             compat_sys_fcntl64
> > 25   64    fcntl                   sys_fcntl
> 
> Don't know, sorry.  I know virtually nothing about the differences
> between the 64-bit and 32-bit ABIs, so I can't comment on anything
> to do with the compat_* interfaces.

The only important factor here is that the first three columns are used
to generate unistd.h, which is the same for both native and emulated
mode, while the last two columns are used to generate two sets of
syscall tables using the same numbers. This is a common requirement
for OABI mode (native or emulated), EABI (on 32-bit or 64-bit kernels)
and the generic ABI (native 32-bit or emulated 32-bit). 

The 64-bit unistd.h is differs only in those syscalls that got replaced
with when loff_t support was added:

#define __NR_fcntl __NR3264_fcntl
#define __NR_statfs __NR3264_statfs
#define __NR_fstatfs __NR3264_fstatfs
#define __NR_truncate __NR3264_truncate
#define __NR_ftruncate __NR3264_ftruncate
#define __NR_lseek __NR3264_lseek
#define __NR_sendfile __NR3264_sendfile
#define __NR_newfstatat __NR3264_fstatat
#define __NR_fstat __NR3264_fstat
#define __NR_mmap __NR3264_mmap
#define __NR_fadvise64 __NR3264_fadvise64
#define __NR_stat __NR3264_stat
#define __NR_lstat __NR3264_lstat

64-bit architectures still use __NR_fcntl, while 32-bit architectures
use __NR_fcntl64 etc.

> > > The syscallnr.sh script kind-of looks like a candidate, but it has
> > > ARM arch specifics to it (knowing that the number of system calls
> > > needs to fit within the 8-bit value plus 4-bit shift constant
> > > representation of ARM ALU instructions.)  Maybe a generic version
> > > without that knowledge would work, provided architectures can
> > > override it.
> > 
> > syscallnr.sh isn't used on x86, and probably won't be needed on
> > most (or all) others, right? 
> 
> Why not - the point of syscallnr.sh is to remove the need to manually
> update the __NR_syscalls definition, which is a generic kernel thing.
> Unless other architectures just define a fixed-size table with plenty
> of extra space, they'd need to adjust __NR_syscalls when adding new
> calls.

Ah, makes sense. I see that x86 does this in
arch/x86/kernel/asm-offsets_64.c in a way that would also work on
other architectures, but being able to share a single script across
all architectures would also help avoid duplicating that code.

	Arnd

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 15:18             ` Arnd Bergmann
  0 siblings, 0 replies; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-21 15:18 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:

> > If we hit this case, why not just use the wrapper on both EABI
> > and OABI for simplicity? It's not like we care a lot about
> > micro-optimizing OABI any more.
> 
> I'd still like to retain the ability to only add to EABI in the future.

Do you mean to add an EABI specific workaround for a specific syscall
if necessary, or to stop adding OABI syscalls altogether?

For the first one, the way that the asm-generic unistd.h handles this is
to have a range of syscall numbers reserved for architecture specific
additions. I was planning to do the same here and have a number of
reserved numbers after the last architecture specific call before
the start of the newly added generic numbers.

> > (or alternatively, add "#define sync_file_range2 arm_sync_file_range"
> > to uapi/asm/unistd.h).
> 
> Well, I think you have a mis-merge somewhere, beacuse uapi/asm/unistd.h
> does have:
> 
> #define __NR_sync_file_range2           __NR_arm_sync_file_range
> 
> in it, which triggers this in scripts/checksyscalls.sh:

That was it, I had merged in my y2038 syscall series for testing and
accidentally dropped that line while rebasing the newly added
syscalls.

> > That brings up an interesting issue: it would be nice to use the
> > same input file for arch/arm/ and the compat mode of arch/arm64,
> > like x86 does. If we handle both oabi and arm64-compat in the same
> > file, we end up with a superset of what x86 does, and we could
> > use a single script again, and generate all four tables for
> > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> 
> OABI-compat != ARM64-EABI-compat though.  They're two completely
> different things.

For the purpose of generating the tables, I don't see much
difference: we either use the fourth column only in native
mode, or we use the fifth column to override values from
the fourth one when emulating the ABI on the "other" kernel.

> Moreover, the syscall numbers ARM64 uses natively are completely
> different from the syscall numbers 32-bit ARM uses, either for EABI
> or OABI.  So I really don't see this working.

That's similar to x86, 32-bit syscalls use the traditional numbers
with an optionally different entry point for compat mode, while
64-bit syscalls use a somewhat reduced table that now has support
for both native 64-bit and "x32" mode. x86-64 and x32 share a
syscall table but not the unistd.h list, all three generated
from syscall_64.tbl.

> I've no idea how ARM64 deals with 32-bit binaries, so I can't comment
> on how it deals with those syscalls, sorry.

ARM64 has a separate list of syscalls for compat mode in 
arch/arm64/include/asm/unistd32.h, this list has the same format
as include/asm-generic/uapi/unistd.h and must be updated manually
to match the arch/arm/ table today.

ARM64 will also likely gain native (A64 instruction set) ILP32
support soon, which will use the same numbers as the 64-bit
mode but point to the compat syscalls. This is similar to
how ARM OABI emulation works.

> > Another related case in asm-generic, which defines three tables:
> > native 32-bit, native 64-bit and compat 32-bit. This one not only
> > needs to have three different function pointers (e.g. sys_fcntl64,
> > sys_fcntl and compat_sys_fcntl64) but also different macros (e.g.
> > __NR_fcntl64 and __NR_fcntl).
> > 
> > Anything wrong with this approach:?
> > 
> > /* ARM */
> > 221  oabi  fcntl64                 sys_fcntl64             sys_oabi_fcntl64
> > 221  eabi  fcntl64                 sys_fcntl64             compat_sys_fcntl64
> > 
> > /* asm-generic */
> > 25   32    fcntl64                 sys_fcntl64             compat_sys_fcntl64
> > 25   64    fcntl                   sys_fcntl
> 
> Don't know, sorry.  I know virtually nothing about the differences
> between the 64-bit and 32-bit ABIs, so I can't comment on anything
> to do with the compat_* interfaces.

The only important factor here is that the first three columns are used
to generate unistd.h, which is the same for both native and emulated
mode, while the last two columns are used to generate two sets of
syscall tables using the same numbers. This is a common requirement
for OABI mode (native or emulated), EABI (on 32-bit or 64-bit kernels)
and the generic ABI (native 32-bit or emulated 32-bit). 

The 64-bit unistd.h is differs only in those syscalls that got replaced
with when loff_t support was added:

#define __NR_fcntl __NR3264_fcntl
#define __NR_statfs __NR3264_statfs
#define __NR_fstatfs __NR3264_fstatfs
#define __NR_truncate __NR3264_truncate
#define __NR_ftruncate __NR3264_ftruncate
#define __NR_lseek __NR3264_lseek
#define __NR_sendfile __NR3264_sendfile
#define __NR_newfstatat __NR3264_fstatat
#define __NR_fstat __NR3264_fstat
#define __NR_mmap __NR3264_mmap
#define __NR_fadvise64 __NR3264_fadvise64
#define __NR_stat __NR3264_stat
#define __NR_lstat __NR3264_lstat

64-bit architectures still use __NR_fcntl, while 32-bit architectures
use __NR_fcntl64 etc.

> > > The syscallnr.sh script kind-of looks like a candidate, but it has
> > > ARM arch specifics to it (knowing that the number of system calls
> > > needs to fit within the 8-bit value plus 4-bit shift constant
> > > representation of ARM ALU instructions.)  Maybe a generic version
> > > without that knowledge would work, provided architectures can
> > > override it.
> > 
> > syscallnr.sh isn't used on x86, and probably won't be needed on
> > most (or all) others, right? 
> 
> Why not - the point of syscallnr.sh is to remove the need to manually
> update the __NR_syscalls definition, which is a generic kernel thing.
> Unless other architectures just define a fixed-size table with plenty
> of extra space, they'd need to adjust __NR_syscalls when adding new
> calls.

Ah, makes sense. I see that x86 does this in
arch/x86/kernel/asm-offsets_64.c in a way that would also work on
other architectures, but being able to share a single script across
all architectures would also help avoid duplicating that code.

	Arnd

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 15:48               ` Russell King - ARM Linux
  0 siblings, 0 replies; 49+ messages in thread
From: Russell King - ARM Linux @ 2016-10-21 15:48 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arch, linux-api

On Fri, Oct 21, 2016 at 05:18:30PM +0200, Arnd Bergmann wrote:
> On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> 
> > > If we hit this case, why not just use the wrapper on both EABI
> > > and OABI for simplicity? It's not like we care a lot about
> > > micro-optimizing OABI any more.
> > 
> > I'd still like to retain the ability to only add to EABI in the future.
> 
> Do you mean to add an EABI specific workaround for a specific syscall
> if necessary, or to stop adding OABI syscalls altogether?

To stop adding OABI syscalls altogether.  I'm sure that there will
come a point (if it hasn't already) that glibc no longer supports
OABI, and at that point it probably becomes rather silly to keep
adding OABI syscalls.

> > > That brings up an interesting issue: it would be nice to use the
> > > same input file for arch/arm/ and the compat mode of arch/arm64,
> > > like x86 does. If we handle both oabi and arm64-compat in the same
> > > file, we end up with a superset of what x86 does, and we could
> > > use a single script again, and generate all four tables for
> > > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> > 
> > OABI-compat != ARM64-EABI-compat though.  They're two completely
> > different things.
> 
> For the purpose of generating the tables, I don't see much
> difference: we either use the fourth column only in native
> mode, or we use the fifth column to override values from
> the fourth one when emulating the ABI on the "other" kernel.

The table generation method can be shared, but I've no idea about the
feasibility of sharing the table between ARM64 and ARM - I don't know
enough about ARM64 to know whether things like an "long" argument to
a syscall (which would be 64-bit on ARM64) would be or would not be a
problem if called from a 32-bit user application.

I've zero knowledge of the whole 32-bit application on 64-bit CPUs
thing, so it's pointless trying to discuss this aspect with me.  Even
for x86, all I care there is that it works, I've no knowledge of how
it works.

> That's similar to x86, 32-bit syscalls use the traditional numbers
> with an optionally different entry point for compat mode, while
> 64-bit syscalls use a somewhat reduced table that now has support
> for both native 64-bit and "x32" mode. x86-64 and x32 share a
> syscall table but not the unistd.h list, all three generated
> from syscall_64.tbl.

What's the point of the x32 mode?

> ARM64 has a separate list of syscalls for compat mode in 
> arch/arm64/include/asm/unistd32.h, this list has the same format
> as include/asm-generic/uapi/unistd.h and must be updated manually
> to match the arch/arm/ table today.

Looking through it, sort-of.  It could have re-used the numbering
from the arch/arm include file, but because ARM64 wanted to be an
entirely separate architecture, it duplicates a lot from 32-bit ARM.
I pointed that out at the time, and was shouted down (which is why
today I have absolutely nothing to do with ARM64, and as a result
have very little knowledge about ARM64 - I lost interest in it as
a result of the responses I got to my comments.)

So... if you don't mind, this isn't an issue I care one iota about.

In order for something to work like what you're alluding to, ARM64
would have to ferret around in arch/arm to pull out the bits it
wants, and I see zero reason for that to be acceptable on either
side of the ARM64 vs ARM divide - it will make my job harder because
I'm then into the position where I need acks from ARM64 people to
change ARM code, and that doesn't interest me at all.  I'm not going
to put myself into a position where I'm at the mercy of ARM64 folk.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 15:48               ` Russell King - ARM Linux
  0 siblings, 0 replies; 49+ messages in thread
From: Russell King - ARM Linux @ 2016-10-21 15:48 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-arch, linux-api

On Fri, Oct 21, 2016 at 05:18:30PM +0200, Arnd Bergmann wrote:
> On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> 
> > > If we hit this case, why not just use the wrapper on both EABI
> > > and OABI for simplicity? It's not like we care a lot about
> > > micro-optimizing OABI any more.
> > 
> > I'd still like to retain the ability to only add to EABI in the future.
> 
> Do you mean to add an EABI specific workaround for a specific syscall
> if necessary, or to stop adding OABI syscalls altogether?

To stop adding OABI syscalls altogether.  I'm sure that there will
come a point (if it hasn't already) that glibc no longer supports
OABI, and at that point it probably becomes rather silly to keep
adding OABI syscalls.

> > > That brings up an interesting issue: it would be nice to use the
> > > same input file for arch/arm/ and the compat mode of arch/arm64,
> > > like x86 does. If we handle both oabi and arm64-compat in the same
> > > file, we end up with a superset of what x86 does, and we could
> > > use a single script again, and generate all four tables for
> > > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> > 
> > OABI-compat != ARM64-EABI-compat though.  They're two completely
> > different things.
> 
> For the purpose of generating the tables, I don't see much
> difference: we either use the fourth column only in native
> mode, or we use the fifth column to override values from
> the fourth one when emulating the ABI on the "other" kernel.

The table generation method can be shared, but I've no idea about the
feasibility of sharing the table between ARM64 and ARM - I don't know
enough about ARM64 to know whether things like an "long" argument to
a syscall (which would be 64-bit on ARM64) would be or would not be a
problem if called from a 32-bit user application.

I've zero knowledge of the whole 32-bit application on 64-bit CPUs
thing, so it's pointless trying to discuss this aspect with me.  Even
for x86, all I care there is that it works, I've no knowledge of how
it works.

> That's similar to x86, 32-bit syscalls use the traditional numbers
> with an optionally different entry point for compat mode, while
> 64-bit syscalls use a somewhat reduced table that now has support
> for both native 64-bit and "x32" mode. x86-64 and x32 share a
> syscall table but not the unistd.h list, all three generated
> from syscall_64.tbl.

What's the point of the x32 mode?

> ARM64 has a separate list of syscalls for compat mode in 
> arch/arm64/include/asm/unistd32.h, this list has the same format
> as include/asm-generic/uapi/unistd.h and must be updated manually
> to match the arch/arm/ table today.

Looking through it, sort-of.  It could have re-used the numbering
from the arch/arm include file, but because ARM64 wanted to be an
entirely separate architecture, it duplicates a lot from 32-bit ARM.
I pointed that out at the time, and was shouted down (which is why
today I have absolutely nothing to do with ARM64, and as a result
have very little knowledge about ARM64 - I lost interest in it as
a result of the responses I got to my comments.)

So... if you don't mind, this isn't an issue I care one iota about.

In order for something to work like what you're alluding to, ARM64
would have to ferret around in arch/arm to pull out the bits it
wants, and I see zero reason for that to be acceptable on either
side of the ARM64 vs ARM divide - it will make my job harder because
I'm then into the position where I need acks from ARM64 people to
change ARM code, and that doesn't interest me at all.  I'm not going
to put myself into a position where I'm at the mercy of ARM64 folk.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 15:48               ` Russell King - ARM Linux
  0 siblings, 0 replies; 49+ messages in thread
From: Russell King - ARM Linux @ 2016-10-21 15:48 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Oct 21, 2016 at 05:18:30PM +0200, Arnd Bergmann wrote:
> On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> 
> > > If we hit this case, why not just use the wrapper on both EABI
> > > and OABI for simplicity? It's not like we care a lot about
> > > micro-optimizing OABI any more.
> > 
> > I'd still like to retain the ability to only add to EABI in the future.
> 
> Do you mean to add an EABI specific workaround for a specific syscall
> if necessary, or to stop adding OABI syscalls altogether?

To stop adding OABI syscalls altogether.  I'm sure that there will
come a point (if it hasn't already) that glibc no longer supports
OABI, and at that point it probably becomes rather silly to keep
adding OABI syscalls.

> > > That brings up an interesting issue: it would be nice to use the
> > > same input file for arch/arm/ and the compat mode of arch/arm64,
> > > like x86 does. If we handle both oabi and arm64-compat in the same
> > > file, we end up with a superset of what x86 does, and we could
> > > use a single script again, and generate all four tables for
> > > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> > 
> > OABI-compat != ARM64-EABI-compat though.  They're two completely
> > different things.
> 
> For the purpose of generating the tables, I don't see much
> difference: we either use the fourth column only in native
> mode, or we use the fifth column to override values from
> the fourth one when emulating the ABI on the "other" kernel.

The table generation method can be shared, but I've no idea about the
feasibility of sharing the table between ARM64 and ARM - I don't know
enough about ARM64 to know whether things like an "long" argument to
a syscall (which would be 64-bit on ARM64) would be or would not be a
problem if called from a 32-bit user application.

I've zero knowledge of the whole 32-bit application on 64-bit CPUs
thing, so it's pointless trying to discuss this aspect with me.  Even
for x86, all I care there is that it works, I've no knowledge of how
it works.

> That's similar to x86, 32-bit syscalls use the traditional numbers
> with an optionally different entry point for compat mode, while
> 64-bit syscalls use a somewhat reduced table that now has support
> for both native 64-bit and "x32" mode. x86-64 and x32 share a
> syscall table but not the unistd.h list, all three generated
> from syscall_64.tbl.

What's the point of the x32 mode?

> ARM64 has a separate list of syscalls for compat mode in 
> arch/arm64/include/asm/unistd32.h, this list has the same format
> as include/asm-generic/uapi/unistd.h and must be updated manually
> to match the arch/arm/ table today.

Looking through it, sort-of.  It could have re-used the numbering
from the arch/arm include file, but because ARM64 wanted to be an
entirely separate architecture, it duplicates a lot from 32-bit ARM.
I pointed that out at the time, and was shouted down (which is why
today I have absolutely nothing to do with ARM64, and as a result
have very little knowledge about ARM64 - I lost interest in it as
a result of the responses I got to my comments.)

So... if you don't mind, this isn't an issue I care one iota about.

In order for something to work like what you're alluding to, ARM64
would have to ferret around in arch/arm to pull out the bits it
wants, and I see zero reason for that to be acceptable on either
side of the ARM64 vs ARM divide - it will make my job harder because
I'm then into the position where I need acks from ARM64 people to
change ARM code, and that doesn't interest me at all.  I'm not going
to put myself into a position where I'm at the mercy of ARM64 folk.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 16:48                   ` Joseph Myers
  0 siblings, 0 replies; 49+ messages in thread
From: Joseph Myers @ 2016-10-21 16:48 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arch, linux-api

On Fri, 21 Oct 2016, Russell King - ARM Linux wrote:

> To stop adding OABI syscalls altogether.  I'm sure that there will
> come a point (if it hasn't already) that glibc no longer supports
> OABI, and at that point it probably becomes rather silly to keep
> adding OABI syscalls.

glibc hasn't supported OABI since 2012 (support removed in version 2.16 
released 2012-06-30).  GCC support was also removed in 2012 (removal 
released in version 4.8, released 2013-03-22).

-- 
Joseph S. Myers
joseph-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 16:48                   ` Joseph Myers
  0 siblings, 0 replies; 49+ messages in thread
From: Joseph Myers @ 2016-10-21 16:48 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Arnd Bergmann, linux-arm-kernel, linux-arch, linux-api

On Fri, 21 Oct 2016, Russell King - ARM Linux wrote:

> To stop adding OABI syscalls altogether.  I'm sure that there will
> come a point (if it hasn't already) that glibc no longer supports
> OABI, and at that point it probably becomes rather silly to keep
> adding OABI syscalls.

glibc hasn't supported OABI since 2012 (support removed in version 2.16 
released 2012-06-30).  GCC support was also removed in 2012 (removal 
released in version 4.8, released 2013-03-22).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 16:48                   ` Joseph Myers
  0 siblings, 0 replies; 49+ messages in thread
From: Joseph Myers @ 2016-10-21 16:48 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 21 Oct 2016, Russell King - ARM Linux wrote:

> To stop adding OABI syscalls altogether.  I'm sure that there will
> come a point (if it hasn't already) that glibc no longer supports
> OABI, and at that point it probably becomes rather silly to keep
> adding OABI syscalls.

glibc hasn't supported OABI since 2012 (support removed in version 2.16 
released 2012-06-30).  GCC support was also removed in 2012 (removal 
released in version 4.8, released 2013-03-22).

-- 
Joseph S. Myers
joseph at codesourcery.com

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 16:57                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 49+ messages in thread
From: Russell King - ARM Linux @ 2016-10-21 16:57 UTC (permalink / raw)
  To: Joseph Myers
  Cc: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arch, linux-api

On Fri, Oct 21, 2016 at 04:48:36PM +0000, Joseph Myers wrote:
> On Fri, 21 Oct 2016, Russell King - ARM Linux wrote:
> 
> > To stop adding OABI syscalls altogether.  I'm sure that there will
> > come a point (if it hasn't already) that glibc no longer supports
> > OABI, and at that point it probably becomes rather silly to keep
> > adding OABI syscalls.
> 
> glibc hasn't supported OABI since 2012 (support removed in version 2.16 
> released 2012-06-30).  GCC support was also removed in 2012 (removal 
> released in version 4.8, released 2013-03-22).

Right, so arguably its pointless adding new syscalls to OABI anymore.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 16:57                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 49+ messages in thread
From: Russell King - ARM Linux @ 2016-10-21 16:57 UTC (permalink / raw)
  To: Joseph Myers; +Cc: Arnd Bergmann, linux-arm-kernel, linux-arch, linux-api

On Fri, Oct 21, 2016 at 04:48:36PM +0000, Joseph Myers wrote:
> On Fri, 21 Oct 2016, Russell King - ARM Linux wrote:
> 
> > To stop adding OABI syscalls altogether.  I'm sure that there will
> > come a point (if it hasn't already) that glibc no longer supports
> > OABI, and at that point it probably becomes rather silly to keep
> > adding OABI syscalls.
> 
> glibc hasn't supported OABI since 2012 (support removed in version 2.16 
> released 2012-06-30).  GCC support was also removed in 2012 (removal 
> released in version 4.8, released 2013-03-22).

Right, so arguably its pointless adding new syscalls to OABI anymore.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 16:57                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 49+ messages in thread
From: Russell King - ARM Linux @ 2016-10-21 16:57 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Oct 21, 2016 at 04:48:36PM +0000, Joseph Myers wrote:
> On Fri, 21 Oct 2016, Russell King - ARM Linux wrote:
> 
> > To stop adding OABI syscalls altogether.  I'm sure that there will
> > come a point (if it hasn't already) that glibc no longer supports
> > OABI, and at that point it probably becomes rather silly to keep
> > adding OABI syscalls.
> 
> glibc hasn't supported OABI since 2012 (support removed in version 2.16 
> released 2012-06-30).  GCC support was also removed in 2012 (removal 
> released in version 4.8, released 2013-03-22).

Right, so arguably its pointless adding new syscalls to OABI anymore.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
  2016-10-21 15:48               ` Russell King - ARM Linux
@ 2016-10-21 20:35                 ` Arnd Bergmann
  -1 siblings, 0 replies; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-21 20:35 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-arch, linux-api

On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
> On Fri, Oct 21, 2016 at 05:18:30PM +0200, Arnd Bergmann wrote:
> > On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> > > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > 
> > > > If we hit this case, why not just use the wrapper on both EABI
> > > > and OABI for simplicity? It's not like we care a lot about
> > > > micro-optimizing OABI any more.
> > > 
> > > I'd still like to retain the ability to only add to EABI in the future.
> > 
> > Do you mean to add an EABI specific workaround for a specific syscall
> > if necessary, or to stop adding OABI syscalls altogether?
> 
> To stop adding OABI syscalls altogether.  I'm sure that there will
> come a point (if it hasn't already) that glibc no longer supports
> OABI, and at that point it probably becomes rather silly to keep
> adding OABI syscalls.

Ok. While uClibc still supports OABI, it seems rather unlikely that
there are active users of OABI uClibc that need any of the future
syscalls.

> > > > That brings up an interesting issue: it would be nice to use the
> > > > same input file for arch/arm/ and the compat mode of arch/arm64,
> > > > like x86 does. If we handle both oabi and arm64-compat in the same
> > > > file, we end up with a superset of what x86 does, and we could
> > > > use a single script again, and generate all four tables for
> > > > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> > > 
> > > OABI-compat != ARM64-EABI-compat though.  They're two completely
> > > different things.
> > 
> > For the purpose of generating the tables, I don't see much
> > difference: we either use the fourth column only in native
> > mode, or we use the fifth column to override values from
> > the fourth one when emulating the ABI on the "other" kernel.
> 
> The table generation method can be shared, but I've no idea about the
> feasibility of sharing the table between ARM64 and ARM - I don't know
> enough about ARM64 to know whether things like an "long" argument to
> a syscall (which would be 64-bit on ARM64) would be or would not be a
> problem if called from a 32-bit user application.
> 
> I've zero knowledge of the whole 32-bit application on 64-bit CPUs
> thing, so it's pointless trying to discuss this aspect with me.  Even
> for x86, all I care there is that it works, I've no knowledge of how
> it works.

Ok. I'm sure it works, but we can definitely leave that for the
time when I or someone else gets around to do the same conversion
for ARM64 that you are doing for ARM32. From all I can tell, it's
a natural extension of the file you already have.

> > That's similar to x86, 32-bit syscalls use the traditional numbers
> > with an optionally different entry point for compat mode, while
> > 64-bit syscalls use a somewhat reduced table that now has support
> > for both native 64-bit and "x32" mode. x86-64 and x32 share a
> > syscall table but not the unistd.h list, all three generated
> > from syscall_64.tbl.
> 
> What's the point of the x32 mode?

On x86, the motivation is faster code for most use cases that
don't need a lot of memory, as the 64-bit opcodes have 16 registers
rather than 8 in 32-bit mode but 32-bit pointers have lower
cache footprint than 64-bit pointers. 

Interestingly, while ARM64 is doing basically the same thing now,
the motivation is almost entirely different: going from around 16
to around 32 registers has a much lower impact on performance
than starting out with 8, but there are ARMv8 implementations that
lack aarch32 mode but still want to run legacy 32-bit code that
is too time-consuming to get 64-bit clean.

> > ARM64 has a separate list of syscalls for compat mode in 
> > arch/arm64/include/asm/unistd32.h, this list has the same format
> > as include/asm-generic/uapi/unistd.h and must be updated manually
> > to match the arch/arm/ table today.
> 
> Looking through it, sort-of.  It could have re-used the numbering
> from the arch/arm include file, but because ARM64 wanted to be an
> entirely separate architecture, it duplicates a lot from 32-bit ARM.
> I pointed that out at the time, and was shouted down (which is why
> today I have absolutely nothing to do with ARM64, and as a result
> have very little knowledge about ARM64 - I lost interest in it as
> a result of the responses I got to my comments.)
> 
> So... if you don't mind, this isn't an issue I care one iota about.
> 
> In order for something to work like what you're alluding to, ARM64
> would have to ferret around in arch/arm to pull out the bits it
> wants, and I see zero reason for that to be acceptable on either
> side of the ARM64 vs ARM divide - it will make my job harder because
> I'm then into the position where I need acks from ARM64 people to
> change ARM code, and that doesn't interest me at all.  I'm not going
> to put myself into a position where I'm at the mercy of ARM64 folk.

Well, if we don't need to worry about OABI any more, using a shared
file for all architectures to add new syscalls (with their compat
handlers) would also mean that you don't have to worry about the
compat handler either, since that gets added in the shared file
along with the syscall.

Then again, if we move the a shared file for new syscalls, we also
don't need to worry about synchronizing the syscall tables for
ARM and compat ARM64, since the files would not get changed any
more.

	Arnd

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-21 20:35                 ` Arnd Bergmann
  0 siblings, 0 replies; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-21 20:35 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
> On Fri, Oct 21, 2016 at 05:18:30PM +0200, Arnd Bergmann wrote:
> > On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> > > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > 
> > > > If we hit this case, why not just use the wrapper on both EABI
> > > > and OABI for simplicity? It's not like we care a lot about
> > > > micro-optimizing OABI any more.
> > > 
> > > I'd still like to retain the ability to only add to EABI in the future.
> > 
> > Do you mean to add an EABI specific workaround for a specific syscall
> > if necessary, or to stop adding OABI syscalls altogether?
> 
> To stop adding OABI syscalls altogether.  I'm sure that there will
> come a point (if it hasn't already) that glibc no longer supports
> OABI, and at that point it probably becomes rather silly to keep
> adding OABI syscalls.

Ok. While uClibc still supports OABI, it seems rather unlikely that
there are active users of OABI uClibc that need any of the future
syscalls.

> > > > That brings up an interesting issue: it would be nice to use the
> > > > same input file for arch/arm/ and the compat mode of arch/arm64,
> > > > like x86 does. If we handle both oabi and arm64-compat in the same
> > > > file, we end up with a superset of what x86 does, and we could
> > > > use a single script again, and generate all four tables for
> > > > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> > > 
> > > OABI-compat != ARM64-EABI-compat though.  They're two completely
> > > different things.
> > 
> > For the purpose of generating the tables, I don't see much
> > difference: we either use the fourth column only in native
> > mode, or we use the fifth column to override values from
> > the fourth one when emulating the ABI on the "other" kernel.
> 
> The table generation method can be shared, but I've no idea about the
> feasibility of sharing the table between ARM64 and ARM - I don't know
> enough about ARM64 to know whether things like an "long" argument to
> a syscall (which would be 64-bit on ARM64) would be or would not be a
> problem if called from a 32-bit user application.
> 
> I've zero knowledge of the whole 32-bit application on 64-bit CPUs
> thing, so it's pointless trying to discuss this aspect with me.  Even
> for x86, all I care there is that it works, I've no knowledge of how
> it works.

Ok. I'm sure it works, but we can definitely leave that for the
time when I or someone else gets around to do the same conversion
for ARM64 that you are doing for ARM32. From all I can tell, it's
a natural extension of the file you already have.

> > That's similar to x86, 32-bit syscalls use the traditional numbers
> > with an optionally different entry point for compat mode, while
> > 64-bit syscalls use a somewhat reduced table that now has support
> > for both native 64-bit and "x32" mode. x86-64 and x32 share a
> > syscall table but not the unistd.h list, all three generated
> > from syscall_64.tbl.
> 
> What's the point of the x32 mode?

On x86, the motivation is faster code for most use cases that
don't need a lot of memory, as the 64-bit opcodes have 16 registers
rather than 8 in 32-bit mode but 32-bit pointers have lower
cache footprint than 64-bit pointers. 

Interestingly, while ARM64 is doing basically the same thing now,
the motivation is almost entirely different: going from around 16
to around 32 registers has a much lower impact on performance
than starting out with 8, but there are ARMv8 implementations that
lack aarch32 mode but still want to run legacy 32-bit code that
is too time-consuming to get 64-bit clean.

> > ARM64 has a separate list of syscalls for compat mode in 
> > arch/arm64/include/asm/unistd32.h, this list has the same format
> > as include/asm-generic/uapi/unistd.h and must be updated manually
> > to match the arch/arm/ table today.
> 
> Looking through it, sort-of.  It could have re-used the numbering
> from the arch/arm include file, but because ARM64 wanted to be an
> entirely separate architecture, it duplicates a lot from 32-bit ARM.
> I pointed that out at the time, and was shouted down (which is why
> today I have absolutely nothing to do with ARM64, and as a result
> have very little knowledge about ARM64 - I lost interest in it as
> a result of the responses I got to my comments.)
> 
> So... if you don't mind, this isn't an issue I care one iota about.
> 
> In order for something to work like what you're alluding to, ARM64
> would have to ferret around in arch/arm to pull out the bits it
> wants, and I see zero reason for that to be acceptable on either
> side of the ARM64 vs ARM divide - it will make my job harder because
> I'm then into the position where I need acks from ARM64 people to
> change ARM code, and that doesn't interest me at all.  I'm not going
> to put myself into a position where I'm at the mercy of ARM64 folk.

Well, if we don't need to worry about OABI any more, using a shared
file for all architectures to add new syscalls (with their compat
handlers) would also mean that you don't have to worry about the
compat handler either, since that gets added in the shared file
along with the syscall.

Then again, if we move the a shared file for new syscalls, we also
don't need to worry about synchronizing the syscall tables for
ARM and compat ARM64, since the files would not get changed any
more.

	Arnd

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-22 20:23                   ` Robert Jarzmik
  0 siblings, 0 replies; 49+ messages in thread
From: Robert Jarzmik @ 2016-10-22 20:23 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Russell King - ARM Linux, linux-arch, linux-api,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:

> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>> What's the point of the x32 mode?
>
> On x86, the motivation is faster code for most use cases that
> don't need a lot of memory, as the 64-bit opcodes have 16 registers
> rather than 8 in 32-bit mode but 32-bit pointers have lower
> cache footprint than 64-bit pointers.

For completness, the second point of x32 AFAIU is the IP-relative addressing
which is not available in standard 32 bit mode, which improves PIC code. For
simple not algorithmic code (think Android HAL for example) with many shared
libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
the push-to-stack and pop register.

Cheers.

--
Robert

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-22 20:23                   ` Robert Jarzmik
  0 siblings, 0 replies; 49+ messages in thread
From: Robert Jarzmik @ 2016-10-22 20:23 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Russell King - ARM Linux, linux-arch, linux-api, linux-arm-kernel

Arnd Bergmann <arnd@arndb.de> writes:

> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>> What's the point of the x32 mode?
>
> On x86, the motivation is faster code for most use cases that
> don't need a lot of memory, as the 64-bit opcodes have 16 registers
> rather than 8 in 32-bit mode but 32-bit pointers have lower
> cache footprint than 64-bit pointers.

For completness, the second point of x32 AFAIU is the IP-relative addressing
which is not available in standard 32 bit mode, which improves PIC code. For
simple not algorithmic code (think Android HAL for example) with many shared
libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
the push-to-stack and pop register.

Cheers.

--
Robert

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-22 20:23                   ` Robert Jarzmik
  0 siblings, 0 replies; 49+ messages in thread
From: Robert Jarzmik @ 2016-10-22 20:23 UTC (permalink / raw)
  To: linux-arm-kernel

Arnd Bergmann <arnd@arndb.de> writes:

> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>> What's the point of the x32 mode?
>
> On x86, the motivation is faster code for most use cases that
> don't need a lot of memory, as the 64-bit opcodes have 16 registers
> rather than 8 in 32-bit mode but 32-bit pointers have lower
> cache footprint than 64-bit pointers.

For completness, the second point of x32 AFAIU is the IP-relative addressing
which is not available in standard 32 bit mode, which improves PIC code. For
simple not algorithmic code (think Android HAL for example) with many shared
libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
the push-to-stack and pop register.

Cheers.

--
Robert

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
  2016-10-22 20:23                   ` Robert Jarzmik
@ 2016-10-24  9:25                     ` Geert Uytterhoeven
  -1 siblings, 0 replies; 49+ messages in thread
From: Geert Uytterhoeven @ 2016-10-24  9:25 UTC (permalink / raw)
  To: Robert Jarzmik
  Cc: Arnd Bergmann, Russell King - ARM Linux, linux-arch, linux-api,
	linux-arm-kernel

On Sat, Oct 22, 2016 at 10:23 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
>> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>>> What's the point of the x32 mode?
>>
>> On x86, the motivation is faster code for most use cases that
>> don't need a lot of memory, as the 64-bit opcodes have 16 registers
>> rather than 8 in 32-bit mode but 32-bit pointers have lower
>> cache footprint than 64-bit pointers.
>
> For completness, the second point of x32 AFAIU is the IP-relative addressing
> which is not available in standard 32 bit mode, which improves PIC code. For
> simple not algorithmic code (think Android HAL for example) with many shared
> libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
> the push-to-stack and pop register.

But that's not an advantage compared to full am64 mode, right?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-24  9:25                     ` Geert Uytterhoeven
  0 siblings, 0 replies; 49+ messages in thread
From: Geert Uytterhoeven @ 2016-10-24  9:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat, Oct 22, 2016 at 10:23 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
>> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>>> What's the point of the x32 mode?
>>
>> On x86, the motivation is faster code for most use cases that
>> don't need a lot of memory, as the 64-bit opcodes have 16 registers
>> rather than 8 in 32-bit mode but 32-bit pointers have lower
>> cache footprint than 64-bit pointers.
>
> For completness, the second point of x32 AFAIU is the IP-relative addressing
> which is not available in standard 32 bit mode, which improves PIC code. For
> simple not algorithmic code (think Android HAL for example) with many shared
> libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
> the push-to-stack and pop register.

But that's not an advantage compared to full am64 mode, right?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-24  9:29         ` Geert Uytterhoeven
  0 siblings, 0 replies; 49+ messages in thread
From: Geert Uytterhoeven @ 2016-10-24  9:29 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Russell King - ARM Linux,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arch,
	linux-api

Hi Arnd,

On Fri, Oct 21, 2016 at 3:06 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> - a lot of the less common architectures just don't get updated
>   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect

Should everybody implement pkey_mprotect?

"x86, pkeys: remove cruft from never-merged syscalls" and

arch/powerpc/include/asm/unistd.h:#define __IGNORE_pkey_mprotect

aren't that reassuring...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-24  9:29         ` Geert Uytterhoeven
  0 siblings, 0 replies; 49+ messages in thread
From: Geert Uytterhoeven @ 2016-10-24  9:29 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Russell King - ARM Linux, linux-arm-kernel, linux-arch, linux-api

Hi Arnd,

On Fri, Oct 21, 2016 at 3:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> - a lot of the less common architectures just don't get updated
>   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect

Should everybody implement pkey_mprotect?

"x86, pkeys: remove cruft from never-merged syscalls" and

arch/powerpc/include/asm/unistd.h:#define __IGNORE_pkey_mprotect

aren't that reassuring...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-24  9:29         ` Geert Uytterhoeven
  0 siblings, 0 replies; 49+ messages in thread
From: Geert Uytterhoeven @ 2016-10-24  9:29 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Arnd,

On Fri, Oct 21, 2016 at 3:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> - a lot of the less common architectures just don't get updated
>   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect

Should everybody implement pkey_mprotect?

"x86, pkeys: remove cruft from never-merged syscalls" and

arch/powerpc/include/asm/unistd.h:#define __IGNORE_pkey_mprotect

aren't that reassuring...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
  2016-10-21 13:06       ` Arnd Bergmann
@ 2016-10-25  9:12         ` Michael Cree
  -1 siblings, 0 replies; 49+ messages in thread
From: Michael Cree @ 2016-10-25  9:12 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Russell King - ARM Linux, linux-arm-kernel, linux-arch,
	linux-api, linux-alpha

On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> I see your point, but I think there are serious issues with the current
> approach as well:
> 
> - a lot of the less common architectures just don't get updated
>   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> 
> - some architectures that add all syscalls sometimes make a mistake
>   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>   did add the later __NR_execveat.

__NR_bpf was not forgotten on Alpha.  It was not wired up because
extra architecture support is needed which has not been implemented.

But maybe we should just wire it up to sys_ni_syscall in the meantime
so a syscall number is reserved for it, and user space can call it to
get -ENOSYS returned.

Cheers
Michael.

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-25  9:12         ` Michael Cree
  0 siblings, 0 replies; 49+ messages in thread
From: Michael Cree @ 2016-10-25  9:12 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> I see your point, but I think there are serious issues with the current
> approach as well:
> 
> - a lot of the less common architectures just don't get updated
>   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> 
> - some architectures that add all syscalls sometimes make a mistake
>   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>   did add the later __NR_execveat.

__NR_bpf was not forgotten on Alpha.  It was not wired up because
extra architecture support is needed which has not been implemented.

But maybe we should just wire it up to sys_ni_syscall in the meantime
so a syscall number is reserved for it, and user space can call it to
get -ENOSYS returned.

Cheers
Michael.

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-25 10:28           ` Arnd Bergmann
  0 siblings, 0 replies; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-25 10:28 UTC (permalink / raw)
  To: Michael Cree
  Cc: Russell King - ARM Linux,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arch,
	linux-api, linux-alpha-u79uwXL29TY76Z2rM5mHXA

On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > I see your point, but I think there are serious issues with the current
> > approach as well:
> > 
> > - a lot of the less common architectures just don't get updated
> >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > 
> > - some architectures that add all syscalls sometimes make a mistake
> >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> >   did add the later __NR_execveat.
> 
> __NR_bpf was not forgotten on Alpha.  It was not wired up because
> extra architecture support is needed which has not been implemented.
> 
> But maybe we should just wire it up to sys_ni_syscall in the meantime
> so a syscall number is reserved for it, and user space can call it to
> get -ENOSYS returned.

Ah, I must have misinterpreted the code then. I assumed that the
bpf syscall always works on all architectures, but that only the
jit compiler for it required architecture specific code to make it
more efficient.

The implementation of sys_bfp is compile-time selectable at the moment
and falls back to sys_no_syscall if CONFIG_BPF_SYSCALL is disabled.
If it doesn't work on Alpha, maybe that symbol could have a "depends
on !ALPHA" or "depends on BPF_SUPPORT"?

sys_seccomp is another one that falls into a similar category, but
it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
architectures have assigned a syscall number but not set this symbol.
This one will actually allow you to set strict seccomp mode even
without the Kconfig symbol, just not allow to set a filter.

	Arnd

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-25 10:28           ` Arnd Bergmann
  0 siblings, 0 replies; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-25 10:28 UTC (permalink / raw)
  To: Michael Cree
  Cc: Russell King - ARM Linux, linux-arm-kernel, linux-arch,
	linux-api, linux-alpha

On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > I see your point, but I think there are serious issues with the current
> > approach as well:
> > 
> > - a lot of the less common architectures just don't get updated
> >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > 
> > - some architectures that add all syscalls sometimes make a mistake
> >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> >   did add the later __NR_execveat.
> 
> __NR_bpf was not forgotten on Alpha.  It was not wired up because
> extra architecture support is needed which has not been implemented.
> 
> But maybe we should just wire it up to sys_ni_syscall in the meantime
> so a syscall number is reserved for it, and user space can call it to
> get -ENOSYS returned.

Ah, I must have misinterpreted the code then. I assumed that the
bpf syscall always works on all architectures, but that only the
jit compiler for it required architecture specific code to make it
more efficient.

The implementation of sys_bfp is compile-time selectable at the moment
and falls back to sys_no_syscall if CONFIG_BPF_SYSCALL is disabled.
If it doesn't work on Alpha, maybe that symbol could have a "depends
on !ALPHA" or "depends on BPF_SUPPORT"?

sys_seccomp is another one that falls into a similar category, but
it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
architectures have assigned a syscall number but not set this symbol.
This one will actually allow you to set strict seccomp mode even
without the Kconfig symbol, just not allow to set a filter.

	Arnd

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-25 10:28           ` Arnd Bergmann
  0 siblings, 0 replies; 49+ messages in thread
From: Arnd Bergmann @ 2016-10-25 10:28 UTC (permalink / raw)
  To: linux-arm-kernel

On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > I see your point, but I think there are serious issues with the current
> > approach as well:
> > 
> > - a lot of the less common architectures just don't get updated
> >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > 
> > - some architectures that add all syscalls sometimes make a mistake
> >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> >   did add the later __NR_execveat.
> 
> __NR_bpf was not forgotten on Alpha.  It was not wired up because
> extra architecture support is needed which has not been implemented.
> 
> But maybe we should just wire it up to sys_ni_syscall in the meantime
> so a syscall number is reserved for it, and user space can call it to
> get -ENOSYS returned.

Ah, I must have misinterpreted the code then. I assumed that the
bpf syscall always works on all architectures, but that only the
jit compiler for it required architecture specific code to make it
more efficient.

The implementation of sys_bfp is compile-time selectable at the moment
and falls back to sys_no_syscall if CONFIG_BPF_SYSCALL is disabled.
If it doesn't work on Alpha, maybe that symbol could have a "depends
on !ALPHA" or "depends on BPF_SUPPORT"?

sys_seccomp is another one that falls into a similar category, but
it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
architectures have assigned a syscall number but not set this symbol.
This one will actually allow you to set strict seccomp mode even
without the Kconfig symbol, just not allow to set a filter.

	Arnd

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-25 17:03             ` Richard Henderson
  0 siblings, 0 replies; 49+ messages in thread
From: Richard Henderson @ 2016-10-25 17:03 UTC (permalink / raw)
  To: Arnd Bergmann, Michael Cree
  Cc: Russell King - ARM Linux,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arch,
	linux-api, linux-alpha-u79uwXL29TY76Z2rM5mHXA

On 10/25/2016 03:28 AM, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
>> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>>> I see your point, but I think there are serious issues with the current
>>> approach as well:
>>>
>>> - a lot of the less common architectures just don't get updated
>>>   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>>>   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
>>>
>>> - some architectures that add all syscalls sometimes make a mistake
>>>   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>>>   did add the later __NR_execveat.
>>
>> __NR_bpf was not forgotten on Alpha.  It was not wired up because
>> extra architecture support is needed which has not been implemented.
>>
>> But maybe we should just wire it up to sys_ni_syscall in the meantime
>> so a syscall number is reserved for it, and user space can call it to
>> get -ENOSYS returned.
> 
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.

That was my interpretation as well.  What's the problem, Michael?


r~

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-25 17:03             ` Richard Henderson
  0 siblings, 0 replies; 49+ messages in thread
From: Richard Henderson @ 2016-10-25 17:03 UTC (permalink / raw)
  To: Arnd Bergmann, Michael Cree
  Cc: Russell King - ARM Linux, linux-arm-kernel, linux-arch,
	linux-api, linux-alpha

On 10/25/2016 03:28 AM, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
>> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>>> I see your point, but I think there are serious issues with the current
>>> approach as well:
>>>
>>> - a lot of the less common architectures just don't get updated
>>>   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>>>   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
>>>
>>> - some architectures that add all syscalls sometimes make a mistake
>>>   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>>>   did add the later __NR_execveat.
>>
>> __NR_bpf was not forgotten on Alpha.  It was not wired up because
>> extra architecture support is needed which has not been implemented.
>>
>> But maybe we should just wire it up to sys_ni_syscall in the meantime
>> so a syscall number is reserved for it, and user space can call it to
>> get -ENOSYS returned.
> 
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.

That was my interpretation as well.  What's the problem, Michael?


r~

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-25 17:03             ` Richard Henderson
  0 siblings, 0 replies; 49+ messages in thread
From: Richard Henderson @ 2016-10-25 17:03 UTC (permalink / raw)
  To: linux-arm-kernel

On 10/25/2016 03:28 AM, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
>> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>>> I see your point, but I think there are serious issues with the current
>>> approach as well:
>>>
>>> - a lot of the less common architectures just don't get updated
>>>   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>>>   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
>>>
>>> - some architectures that add all syscalls sometimes make a mistake
>>>   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>>>   did add the later __NR_execveat.
>>
>> __NR_bpf was not forgotten on Alpha.  It was not wired up because
>> extra architecture support is needed which has not been implemented.
>>
>> But maybe we should just wire it up to sys_ni_syscall in the meantime
>> so a syscall number is reserved for it, and user space can call it to
>> get -ENOSYS returned.
> 
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.

That was my interpretation as well.  What's the problem, Michael?


r~

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-25 17:09             ` Geert Uytterhoeven
  0 siblings, 0 replies; 49+ messages in thread
From: Geert Uytterhoeven @ 2016-10-25 17:09 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, Michael Cree, linux-api, Russell King - ARM Linux,
	alpha, linux-arm-kernel

On Tue, Oct 25, 2016 at 12:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
>> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>> > I see your point, but I think there are serious issues with the current
>> > approach as well:
>> >
>> > - a lot of the less common architectures just don't get updated
>> >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>> >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
>> >
>> > - some architectures that add all syscalls sometimes make a mistake
>> >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>> >   did add the later __NR_execveat.
>>
>> __NR_bpf was not forgotten on Alpha.  It was not wired up because
>> extra architecture support is needed which has not been implemented.
>>
>> But maybe we should just wire it up to sys_ni_syscall in the meantime
>> so a syscall number is reserved for it, and user space can call it to
>> get -ENOSYS returned.
>
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.
>
> The implementation of sys_bfp is compile-time selectable at the moment
> and falls back to sys_no_syscall if CONFIG_BPF_SYSCALL is disabled.
> If it doesn't work on Alpha, maybe that symbol could have a "depends
> on !ALPHA" or "depends on BPF_SUPPORT"?

Yes, BPF should just work (m68k has it).

> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.

Seccomp needs architecture support (m68k doesn't have it).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-25 17:09             ` Geert Uytterhoeven
  0 siblings, 0 replies; 49+ messages in thread
From: Geert Uytterhoeven @ 2016-10-25 17:09 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Michael Cree, Russell King - ARM Linux, linux-arm-kernel,
	linux-arch, linux-api, alpha

On Tue, Oct 25, 2016 at 12:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
>> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>> > I see your point, but I think there are serious issues with the current
>> > approach as well:
>> >
>> > - a lot of the less common architectures just don't get updated
>> >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>> >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
>> >
>> > - some architectures that add all syscalls sometimes make a mistake
>> >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>> >   did add the later __NR_execveat.
>>
>> __NR_bpf was not forgotten on Alpha.  It was not wired up because
>> extra architecture support is needed which has not been implemented.
>>
>> But maybe we should just wire it up to sys_ni_syscall in the meantime
>> so a syscall number is reserved for it, and user space can call it to
>> get -ENOSYS returned.
>
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.
>
> The implementation of sys_bfp is compile-time selectable at the moment
> and falls back to sys_no_syscall if CONFIG_BPF_SYSCALL is disabled.
> If it doesn't work on Alpha, maybe that symbol could have a "depends
> on !ALPHA" or "depends on BPF_SUPPORT"?

Yes, BPF should just work (m68k has it).

> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.

Seccomp needs architecture support (m68k doesn't have it).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-25 17:09             ` Geert Uytterhoeven
  0 siblings, 0 replies; 49+ messages in thread
From: Geert Uytterhoeven @ 2016-10-25 17:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Oct 25, 2016 at 12:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
>> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>> > I see your point, but I think there are serious issues with the current
>> > approach as well:
>> >
>> > - a lot of the less common architectures just don't get updated
>> >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>> >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
>> >
>> > - some architectures that add all syscalls sometimes make a mistake
>> >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>> >   did add the later __NR_execveat.
>>
>> __NR_bpf was not forgotten on Alpha.  It was not wired up because
>> extra architecture support is needed which has not been implemented.
>>
>> But maybe we should just wire it up to sys_ni_syscall in the meantime
>> so a syscall number is reserved for it, and user space can call it to
>> get -ENOSYS returned.
>
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.
>
> The implementation of sys_bfp is compile-time selectable at the moment
> and falls back to sys_no_syscall if CONFIG_BPF_SYSCALL is disabled.
> If it doesn't work on Alpha, maybe that symbol could have a "depends
> on !ALPHA" or "depends on BPF_SUPPORT"?

Yes, BPF should just work (m68k has it).

> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.

Seccomp needs architecture support (m68k doesn't have it).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
  2016-10-25 10:28           ` Arnd Bergmann
@ 2016-10-26  7:04             ` Michael Cree
  -1 siblings, 0 replies; 49+ messages in thread
From: Michael Cree @ 2016-10-26  7:04 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Russell King - ARM Linux, linux-arm-kernel, linux-arch,
	linux-api, linux-alpha

On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > I see your point, but I think there are serious issues with the current
> > > approach as well:
> > > 
> > > - a lot of the less common architectures just don't get updated
> > >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > > 
> > > - some architectures that add all syscalls sometimes make a mistake
> > >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > >   did add the later __NR_execveat.
> > 
> > __NR_bpf was not forgotten on Alpha.  It was not wired up because
> > extra architecture support is needed which has not been implemented.
> > 
> > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > so a syscall number is reserved for it, and user space can call it to
> > get -ENOSYS returned.
> 
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.

Oh.  When someone posted wiring up of syscalls on Alpha some time
back I raised a query about seccomp then someone else (I can't be
bothered looking up the old emails, it doesn't really matter)
said bpf was in the same basket, so the patch was re-submitted with
neither of those syscalls.

> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.

We have got way behind on syscalls on Alpha and I was just in the
process of wiring them up and testing them, so I will include both
seccomp and bpf in that.

Cheers
Michael.

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-26  7:04             ` Michael Cree
  0 siblings, 0 replies; 49+ messages in thread
From: Michael Cree @ 2016-10-26  7:04 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > I see your point, but I think there are serious issues with the current
> > > approach as well:
> > > 
> > > - a lot of the less common architectures just don't get updated
> > >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > > 
> > > - some architectures that add all syscalls sometimes make a mistake
> > >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > >   did add the later __NR_execveat.
> > 
> > __NR_bpf was not forgotten on Alpha.  It was not wired up because
> > extra architecture support is needed which has not been implemented.
> > 
> > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > so a syscall number is reserved for it, and user space can call it to
> > get -ENOSYS returned.
> 
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.

Oh.  When someone posted wiring up of syscalls on Alpha some time
back I raised a query about seccomp then someone else (I can't be
bothered looking up the old emails, it doesn't really matter)
said bpf was in the same basket, so the patch was re-submitted with
neither of those syscalls.

> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.

We have got way behind on syscalls on Alpha and I was just in the
process of wiring them up and testing them, so I will include both
seccomp and bpf in that.

Cheers
Michael.

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

* bpf on Alpha [was Re: [PATCH 2/3] ARM: convert to generated system call tables]
@ 2016-10-26  9:12               ` Michael Cree
  0 siblings, 0 replies; 49+ messages in thread
From: Michael Cree @ 2016-10-26  9:12 UTC (permalink / raw)
  To: Arnd Bergmann, Russell King - ARM Linux,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arch,
	linux-api, linux-alpha-u79uwXL29TY76Z2rM5mHXA

On Wed, Oct 26, 2016 at 08:04:30PM +1300, Michael Cree wrote:
> On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> > On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > > I see your point, but I think there are serious issues with the current
> > > > approach as well:
> > > > 
> > > > - a lot of the less common architectures just don't get updated
> > > >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > > >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > > > 
> > > > - some architectures that add all syscalls sometimes make a mistake
> > > >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > > >   did add the later __NR_execveat.
> > > 
> > > __NR_bpf was not forgotten on Alpha.  It was not wired up because
> > > extra architecture support is needed which has not been implemented.
> > > 
> > > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > > so a syscall number is reserved for it, and user space can call it to
> > > get -ENOSYS returned.
> > 
> > Ah, I must have misinterpreted the code then. I assumed that the
> > bpf syscall always works on all architectures, but that only the
> > jit compiler for it required architecture specific code to make it
> > more efficient.
> 
> Oh.  When someone posted wiring up of syscalls on Alpha some time
> back I raised a query about seccomp then someone else (I can't be
> bothered looking up the old emails, it doesn't really matter)
> said bpf was in the same basket, so the patch was re-submitted with
> neither of those syscalls.
> 
> > sys_seccomp is another one that falls into a similar category, but
> > it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> > architectures have assigned a syscall number but not set this symbol.
> > This one will actually allow you to set strict seccomp mode even
> > without the Kconfig symbol, just not allow to set a filter.
> 
> We have got way behind on syscalls on Alpha and I was just in the
> process of wiring them up and testing them, so I will include both
> seccomp and bpf in that.

Having just wired up bpf on an Alpha and run samples/bpf/test_verifier
I get:

#0 add+sub+mul OK
#1 unreachable OK
#2 unreachable2 OK
#3 out of range jump OK

[snip many passing tests]

#69 unpriv: check that printk is disallowed FAIL
failed to load prog 'Invalid argument'
0: (7a) *(u64 *)(r10 -8) = 0
1: (bf) r1 = r10
2: (07) r1 += -8
3: (b7) r2 = 8
4: (bf) r3 = r1
5: (85) call 6
unknown func 6

[snip many more passing tests]

Summary: 101 PASSED, 1 FAILED

Should I be concerned about the failing #69 test?

Cheers
Michael.

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

* bpf on Alpha [was Re: [PATCH 2/3] ARM: convert to generated system call tables]
@ 2016-10-26  9:12               ` Michael Cree
  0 siblings, 0 replies; 49+ messages in thread
From: Michael Cree @ 2016-10-26  9:12 UTC (permalink / raw)
  To: Arnd Bergmann, Russell King - ARM Linux, linux-arm-kernel,
	linux-arch, linux-api, linux-alpha

On Wed, Oct 26, 2016 at 08:04:30PM +1300, Michael Cree wrote:
> On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> > On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > > I see your point, but I think there are serious issues with the current
> > > > approach as well:
> > > > 
> > > > - a lot of the less common architectures just don't get updated
> > > >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > > >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > > > 
> > > > - some architectures that add all syscalls sometimes make a mistake
> > > >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > > >   did add the later __NR_execveat.
> > > 
> > > __NR_bpf was not forgotten on Alpha.  It was not wired up because
> > > extra architecture support is needed which has not been implemented.
> > > 
> > > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > > so a syscall number is reserved for it, and user space can call it to
> > > get -ENOSYS returned.
> > 
> > Ah, I must have misinterpreted the code then. I assumed that the
> > bpf syscall always works on all architectures, but that only the
> > jit compiler for it required architecture specific code to make it
> > more efficient.
> 
> Oh.  When someone posted wiring up of syscalls on Alpha some time
> back I raised a query about seccomp then someone else (I can't be
> bothered looking up the old emails, it doesn't really matter)
> said bpf was in the same basket, so the patch was re-submitted with
> neither of those syscalls.
> 
> > sys_seccomp is another one that falls into a similar category, but
> > it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> > architectures have assigned a syscall number but not set this symbol.
> > This one will actually allow you to set strict seccomp mode even
> > without the Kconfig symbol, just not allow to set a filter.
> 
> We have got way behind on syscalls on Alpha and I was just in the
> process of wiring them up and testing them, so I will include both
> seccomp and bpf in that.

Having just wired up bpf on an Alpha and run samples/bpf/test_verifier
I get:

#0 add+sub+mul OK
#1 unreachable OK
#2 unreachable2 OK
#3 out of range jump OK

[snip many passing tests]

#69 unpriv: check that printk is disallowed FAIL
failed to load prog 'Invalid argument'
0: (7a) *(u64 *)(r10 -8) = 0
1: (bf) r1 = r10
2: (07) r1 += -8
3: (b7) r2 = 8
4: (bf) r3 = r1
5: (85) call 6
unknown func 6

[snip many more passing tests]

Summary: 101 PASSED, 1 FAILED

Should I be concerned about the failing #69 test?

Cheers
Michael.

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

* bpf on Alpha [was Re: [PATCH 2/3] ARM: convert to generated system call tables]
@ 2016-10-26  9:12               ` Michael Cree
  0 siblings, 0 replies; 49+ messages in thread
From: Michael Cree @ 2016-10-26  9:12 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Oct 26, 2016 at 08:04:30PM +1300, Michael Cree wrote:
> On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> > On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > > I see your point, but I think there are serious issues with the current
> > > > approach as well:
> > > > 
> > > > - a lot of the less common architectures just don't get updated
> > > >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > > >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > > > 
> > > > - some architectures that add all syscalls sometimes make a mistake
> > > >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > > >   did add the later __NR_execveat.
> > > 
> > > __NR_bpf was not forgotten on Alpha.  It was not wired up because
> > > extra architecture support is needed which has not been implemented.
> > > 
> > > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > > so a syscall number is reserved for it, and user space can call it to
> > > get -ENOSYS returned.
> > 
> > Ah, I must have misinterpreted the code then. I assumed that the
> > bpf syscall always works on all architectures, but that only the
> > jit compiler for it required architecture specific code to make it
> > more efficient.
> 
> Oh.  When someone posted wiring up of syscalls on Alpha some time
> back I raised a query about seccomp then someone else (I can't be
> bothered looking up the old emails, it doesn't really matter)
> said bpf was in the same basket, so the patch was re-submitted with
> neither of those syscalls.
> 
> > sys_seccomp is another one that falls into a similar category, but
> > it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> > architectures have assigned a syscall number but not set this symbol.
> > This one will actually allow you to set strict seccomp mode even
> > without the Kconfig symbol, just not allow to set a filter.
> 
> We have got way behind on syscalls on Alpha and I was just in the
> process of wiring them up and testing them, so I will include both
> seccomp and bpf in that.

Having just wired up bpf on an Alpha and run samples/bpf/test_verifier
I get:

#0 add+sub+mul OK
#1 unreachable OK
#2 unreachable2 OK
#3 out of range jump OK

[snip many passing tests]

#69 unpriv: check that printk is disallowed FAIL
failed to load prog 'Invalid argument'
0: (7a) *(u64 *)(r10 -8) = 0
1: (bf) r1 = r10
2: (07) r1 += -8
3: (b7) r2 = 8
4: (bf) r3 = r1
5: (85) call 6
unknown func 6

[snip many more passing tests]

Summary: 101 PASSED, 1 FAILED

Should I be concerned about the failing #69 test?

Cheers
Michael.

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-26 20:14                         ` Robert Jarzmik
  0 siblings, 0 replies; 49+ messages in thread
From: Robert Jarzmik @ 2016-10-26 20:14 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Arnd Bergmann, Russell King - ARM Linux, linux-arch, linux-api,
	linux-arm-kernel@lists.infradead.org

Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> writes:

> On Sat, Oct 22, 2016 at 10:23 PM, Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> wrote:
>> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
>>
>>> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>>>> What's the point of the x32 mode?
>>>
>>> On x86, the motivation is faster code for most use cases that
>>> don't need a lot of memory, as the 64-bit opcodes have 16 registers
>>> rather than 8 in 32-bit mode but 32-bit pointers have lower
>>> cache footprint than 64-bit pointers.
>>
>> For completness, the second point of x32 AFAIU is the IP-relative addressing
>> which is not available in standard 32 bit mode, which improves PIC code. For
>> simple not algorithmic code (think Android HAL for example) with many shared
>> libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
>> the push-to-stack and pop register.
>
> But that's not an advantage compared to full am64 mode, right?
Nope, the amd64 (that's what you have in mind with am64, not aarch64 right ?)
mode has the IP-relative has well, so x32 has no advantage over amd64 in this
area.

x32 over amd64 advantage is cache and memory footprint AFAICT, I don't see other
benefits. There doesn't seem to be any ISA differences, or I didn't really
notice in my daily system performance analysis job.

There was a nice presentation made by Peter Anvin at a Plumber conference, here
: http://linuxplumbersconf.org/2011/ocw/sessions/531

Cheers.

-- 
Robert

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

* Re: [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-26 20:14                         ` Robert Jarzmik
  0 siblings, 0 replies; 49+ messages in thread
From: Robert Jarzmik @ 2016-10-26 20:14 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Arnd Bergmann, Russell King - ARM Linux, linux-arch, linux-api,
	linux-arm-kernel

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Sat, Oct 22, 2016 at 10:23 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>
>>> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>>>> What's the point of the x32 mode?
>>>
>>> On x86, the motivation is faster code for most use cases that
>>> don't need a lot of memory, as the 64-bit opcodes have 16 registers
>>> rather than 8 in 32-bit mode but 32-bit pointers have lower
>>> cache footprint than 64-bit pointers.
>>
>> For completness, the second point of x32 AFAIU is the IP-relative addressing
>> which is not available in standard 32 bit mode, which improves PIC code. For
>> simple not algorithmic code (think Android HAL for example) with many shared
>> libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
>> the push-to-stack and pop register.
>
> But that's not an advantage compared to full am64 mode, right?
Nope, the amd64 (that's what you have in mind with am64, not aarch64 right ?)
mode has the IP-relative has well, so x32 has no advantage over amd64 in this
area.

x32 over amd64 advantage is cache and memory footprint AFAICT, I don't see other
benefits. There doesn't seem to be any ISA differences, or I didn't really
notice in my daily system performance analysis job.

There was a nice presentation made by Peter Anvin at a Plumber conference, here
: http://linuxplumbersconf.org/2011/ocw/sessions/531

Cheers.

-- 
Robert

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

* [PATCH 2/3] ARM: convert to generated system call tables
@ 2016-10-26 20:14                         ` Robert Jarzmik
  0 siblings, 0 replies; 49+ messages in thread
From: Robert Jarzmik @ 2016-10-26 20:14 UTC (permalink / raw)
  To: linux-arm-kernel

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Sat, Oct 22, 2016 at 10:23 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>
>>> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>>>> What's the point of the x32 mode?
>>>
>>> On x86, the motivation is faster code for most use cases that
>>> don't need a lot of memory, as the 64-bit opcodes have 16 registers
>>> rather than 8 in 32-bit mode but 32-bit pointers have lower
>>> cache footprint than 64-bit pointers.
>>
>> For completness, the second point of x32 AFAIU is the IP-relative addressing
>> which is not available in standard 32 bit mode, which improves PIC code. For
>> simple not algorithmic code (think Android HAL for example) with many shared
>> libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
>> the push-to-stack and pop register.
>
> But that's not an advantage compared to full am64 mode, right?
Nope, the amd64 (that's what you have in mind with am64, not aarch64 right ?)
mode has the IP-relative has well, so x32 has no advantage over amd64 in this
area.

x32 over amd64 advantage is cache and memory footprint AFAICT, I don't see other
benefits. There doesn't seem to be any ISA differences, or I didn't really
notice in my daily system performance analysis job.

There was a nice presentation made by Peter Anvin at a Plumber conference, here
: http://linuxplumbersconf.org/2011/ocw/sessions/531

Cheers.

-- 
Robert

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

end of thread, other threads:[~2016-10-26 20:15 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-18 19:31 [PATCH 2/3] ARM: convert to generated system call tables Russell King
2016-10-19 15:30 ` Arnd Bergmann
2016-10-19 15:53   ` Russell King - ARM Linux
2016-10-21 13:06     ` Arnd Bergmann
2016-10-21 13:06       ` Arnd Bergmann
2016-10-21 13:37       ` Russell King - ARM Linux
2016-10-21 13:37         ` Russell King - ARM Linux
2016-10-21 13:37         ` Russell King - ARM Linux
     [not found]         ` <20161021133708.GA1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
2016-10-21 15:18           ` Arnd Bergmann
2016-10-21 15:18             ` Arnd Bergmann
2016-10-21 15:18             ` Arnd Bergmann
2016-10-21 15:48             ` Russell King - ARM Linux
2016-10-21 15:48               ` Russell King - ARM Linux
2016-10-21 15:48               ` Russell King - ARM Linux
     [not found]               ` <20161021154856.GC1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
2016-10-21 16:48                 ` Joseph Myers
2016-10-21 16:48                   ` Joseph Myers
2016-10-21 16:48                   ` Joseph Myers
     [not found]                   ` <alpine.DEB.2.20.1610211641430.27636-9YEB1lltEqivcGRMvF24k2I39yigxGEX@public.gmane.org>
2016-10-21 16:57                     ` Russell King - ARM Linux
2016-10-21 16:57                       ` Russell King - ARM Linux
2016-10-21 16:57                       ` Russell King - ARM Linux
2016-10-21 20:35               ` Arnd Bergmann
2016-10-21 20:35                 ` Arnd Bergmann
2016-10-22 20:23                 ` Robert Jarzmik
2016-10-22 20:23                   ` Robert Jarzmik
2016-10-22 20:23                   ` Robert Jarzmik
2016-10-24  9:25                   ` Geert Uytterhoeven
2016-10-24  9:25                     ` Geert Uytterhoeven
     [not found]                     ` <CAMuHMdVy_h6Uss9bwVK5hGD42bXeEBcBsBDwCpx_eYnT9r+=Lw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-26 20:14                       ` Robert Jarzmik
2016-10-26 20:14                         ` Robert Jarzmik
2016-10-26 20:14                         ` Robert Jarzmik
2016-10-24  9:29       ` Geert Uytterhoeven
2016-10-24  9:29         ` Geert Uytterhoeven
2016-10-24  9:29         ` Geert Uytterhoeven
2016-10-25  9:12       ` Michael Cree
2016-10-25  9:12         ` Michael Cree
2016-10-25 10:28         ` Arnd Bergmann
2016-10-25 10:28           ` Arnd Bergmann
2016-10-25 10:28           ` Arnd Bergmann
2016-10-25 17:03           ` Richard Henderson
2016-10-25 17:03             ` Richard Henderson
2016-10-25 17:03             ` Richard Henderson
2016-10-25 17:09           ` Geert Uytterhoeven
2016-10-25 17:09             ` Geert Uytterhoeven
2016-10-25 17:09             ` Geert Uytterhoeven
2016-10-26  7:04           ` Michael Cree
2016-10-26  7:04             ` Michael Cree
2016-10-26  9:12             ` bpf on Alpha [was Re: [PATCH 2/3] ARM: convert to generated system call tables] Michael Cree
2016-10-26  9:12               ` Michael Cree
2016-10-26  9:12               ` Michael Cree

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.