[patch 00/18] entry: Consolidate and rework syscall entry handling
From: Thomas Gleixner <tglx@kernel.org>
Date: 2026-07-07 19:05:57
Also in:
linux-alpha, linux-arch, linux-doc, linux-m68k, linux-mips, linux-riscv, linux-s390, linux-sh, linux-um, lkml, loongarch, sparclinux
Sorry for the long CC list, but this is a treewide change. Michal recently posted a RFC patch to separate the potential syscall number modifications in syscall_enter_user_mode_work() from the information whether the syscall should be processed and the return value modified: https://lore.kernel.org/lkml/CE1qW@kunlun.suse.cz The existing logic is: arch_syscall() regs->result = -ENOSYS; syscallnr = syscall_enter_from_user_mode(regs, syscall); if (syscallnr != -1L) regs->result = invoke_syscall(regs, syscall; syscall_enter_from_user_mode() invokes ptrace, seccomp and tracing/BPF/Probes. All of them can modify the syscall number. ptrace and seccomp explicitly set the syscall number to -1L to indicate that the syscall invocation needs to be skipped and the result has not to be modified as it might have been modified by ptrace or seccomp. The tracer/BPF/Probes mechanism can modify the syscall number as well and relies implicitly on the -1L logic. This can obviously not be differentiated from a syscall invocation where userspace provided -1 as syscall number. The general agreement of the discussion was that the current mechanism, while functionally correct is non-intuitive and something like Michals proposal would make that code clearer and easier to handle on the architecture side: arch_syscall() regs->result = -ENOSYS; if (syscall_enter_from_user_mode(regs, &syscall)) regs->result = invoke_syscall(regs, syscall; That discussion made me look deeper into the related code and as usual there were a lot of other things to discover. 1) Stack randomization add_random_kstack_offset() can only be invoked after enter_from_user_mode() established proper state as it calls into instrumentable code. PowerPC got that wrong and the other architectures either invoke it after enter_from_user_mode() or after syscall_enter_from_user_mode(). The latter is suboptimal as the randomization takes place after all the user mode entry work. Aside of that add_random_kstack_offset() uses get/put_cpu_var(), which makes it usable in preemptible code, but when invoked in the interrupt disabled region that's pointless overhead. 2) As discussed in the above thread just changing the function signature of syscall_enter_from_user_mode[_work]() so they take a pointer argument for the syscall and then return 0 on success is not really intuitive either. Aside of that this breaks the implicit assumption of the tracer when setting the syscall number to -1. 3) The x86 entry code has some historically accumulated oddities The following series addresses this by: 1) Providing new [syscall_]enter_from_user_mode() variants, which include stack randomization and utilize a new add_random_kstack_offset_irqsoff() variant, which avoids the get/put_cpu_var() overhead and converting all usage sites over 2) Picking up Jinjie's seccomp patch from: https://lore.kernel.org/lkml/20260629130616.642022-2-ruanjinjie@huawei.com (local) and addressing the feedback (renaming the seccomp functions) 3) Making the ptrace and tracer related functions return a boolean value to indicate syscall permission 4) Addressing the x86 oddities 5) Converting the tree over to the new scheme With that all architectures using the generic syscall entry code follow the same scheme, apply stack randomization at the correct and earliest possible place and skip syscall processing depending on the boolean return value of syscall_enter_from_user_mode[_work](). There should be no functional changes, at least there are none intended. The resulting text size for the syscall entry code on x8664 is slightly smaller than before these changes. Testing syscall heavy workloads and micro benchmarks shows a small performance gain for the general rework, but the last patch, which changes the logic to be more understandable has no measurable impact in either direction. The series applies on Linus tree and is also available from git: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git entry-rework-v1 Thanks, tglx --- Documentation/core-api/entry.rst | 33 +++++--- arch/alpha/kernel/ptrace.c | 4 - arch/arc/kernel/ptrace.c | 2 arch/arm/kernel/ptrace.c | 4 - arch/arm64/kernel/ptrace.c | 4 - arch/csky/kernel/ptrace.c | 4 - arch/hexagon/kernel/traps.c | 2 arch/loongarch/kernel/syscall.c | 17 +--- arch/m68k/kernel/ptrace.c | 4 - arch/microblaze/kernel/ptrace.c | 2 arch/mips/kernel/ptrace.c | 4 - arch/nios2/kernel/ptrace.c | 2 arch/openrisc/kernel/ptrace.c | 2 arch/parisc/kernel/ptrace.c | 12 +-- arch/powerpc/kernel/syscall.c | 5 - arch/riscv/kernel/traps.c | 14 +-- arch/s390/kernel/syscall.c | 11 +- arch/sh/kernel/ptrace_32.c | 4 - arch/sparc/kernel/ptrace_32.c | 2 arch/sparc/kernel/ptrace_64.c | 2 arch/um/kernel/ptrace.c | 2 arch/um/kernel/skas/syscall.c | 2 arch/x86/entry/syscall_32.c | 70 +++++++------------ arch/x86/entry/syscall_64.c | 61 ++++++---------- arch/x86/entry/vsyscall/vsyscall_64.c | 14 +-- arch/x86/include/asm/entry-common.h | 1 arch/x86/include/asm/syscall.h | 10 -- arch/xtensa/kernel/ptrace.c | 5 - include/asm-generic/syscall.h | 4 - include/linux/entry-common.h | 125 ++++++++++++++++++++-------------- include/linux/irq-entry-common.h | 6 - include/linux/ptrace.h | 13 +-- include/linux/randomize_kstack.h | 19 +++++ include/linux/seccomp.h | 12 +-- kernel/entry/syscall-common.c | 7 + kernel/seccomp.c | 35 ++++----- 36 files changed, 264 insertions(+), 256 deletions(-)