[patch 00/18] entry: Consolidate and rework syscall entry handling
Mukesh Kumar Chaurasiya
mkchauras at gmail.com
Thu Jul 9 13:15:19 PDT 2026
On Tue, Jul 07, 2026 at 09:05:53PM +0200, Thomas Gleixner wrote:
> 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
>
> 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(-)
>
>
>
> _______________________________________________
> linux-snps-arc mailing list
> linux-snps-arc at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Boot tested this on P11 LPAR and P9 powernv system.
Tested-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras at gmail.com>
More information about the linux-riscv
mailing list