Re: [patch 13/18] entry: Make trace_syscall_enter() return type bool

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:

quoted

On Wed, Jul 08, 2026 at 10:34:38PM +0200, Thomas Gleixner wrote:

quoted

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