On Sat, Jul 11, 2026 at 10:33:16PM +0200, Thomas Gleixner wrote:
> Michal!
>
> On Fri, Jul 10 2026 at 13:01, Michal Suchánek wrote:
> > On Wed, Jul 08, 2026 at 10:34:38PM +0200, Thomas Gleixner wrote:
> >> does not make #2 magically go away. It's still the same problem whether
> >> you like it or not.
> >
> > However, reading the syscall number from pt_regs only after
> > syscall_enter_from_user_mode exits does.
>
> That does not solve anything at all.
>
> TBH, your communication style is annoying as hell. You fail to provide
> any useful arguments and explanations despite me giving you a proper
> analysis. And I'm absolutely tired of this.
>
> So let me try again for _ONE_ last time to explain you why your ppc/s390
> world view is broken and let's look at the current code (irrelevant
> portions omitted).
>
> static __always_inline long syscall_trace_enter(struct pt_regs *regs,
> unsigned long work)
> {
> if (work & SYSCALL_WORK_SYSCALL_USER_DISPATCH) {
> #1 if (syscall_user_dispatch(regs))
> return -1L;
> }
>
> if (work & (SYSCALL_WORK_SYSCALL_TRACE | SYSCALL_WORK_SYSCALL_EMU)) {
> #2 ret = arch_ptrace_report_syscall_entry(regs);
> if (ret || (work & SYSCALL_WORK_SYSCALL_EMU))
> return -1L;
> }
>
> /* Do seccomp after ptrace, to catch any tracer changes. */
> if (work & SYSCALL_WORK_SECCOMP) {
> #3 ret = __secure_computing();
> if (ret == -1L)
> return ret;
> }
>
> /* Either of the above might have changed the syscall number */
> #4 syscall = syscall_get_nr(current, regs);
>
> if (unlikely(work & SYSCALL_WORK_SYSCALL_TRACEPOINT))
> #5 syscall = trace_syscall_enter(regs, syscall);
>
> return syscall;
> }
>
> #1) The user dispatch mechanism does not modify the syscall return
> value, but it can rollback the syscall and tell the call site to
> skip the invocation.
>
> The mechanism used in upstream today is to return -1L as the syscall
> number which makes the architecture specific entry code skip the
> syscall and refrain from touching the return value.
>
> #2) ptrace
>
> ptrace can poke whatever it wants into the syscall number storage
> via ptrace_set_syscall_info_entry() -> syscall_set_nr()
>
> It does not set the return code.
>
> It does not abort the syscall when the poked syscall number is -1L.
Indeed, it does not abort on -1 syscall number anymore although there
are still comments around that claim that setting the syscall number to
-1 is special.
Thanks
Michal
