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/[email protected] > > 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/[email protected] > > 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 > [email protected] > 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) <[email protected]>
