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

[Thomas Gleixner <tglx@kernel.org>]

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.

    It only aborts when a fatal signal is pending.

#3) seccomp

    seccomp reads the syscall number, which might have been modified by
    ptrace and acts upon it.

    It can rewrite the syscall number even if it is -1 to begin with.

    It can rewrite the return code if it decides to refuse the syscall
    to be executed.

    If it refuses the syscall to be executed it returns -1L.

#4) Rereading the syscall number after ptrace/seccomp

    That's required to give the eventually modified number to the
    tracer.

    Obviously the tracer could do that on it's own, but with the current
    implementation it expects the eventually modified syscall number

    Changing that to make the tracer do it, is possible but does not
    change any of the actual expectations. That's just cosmetic wankery.

#5) tracing

    tracing can have a probe or bpf attached, which in turn can

      - rewrite the syscall number

      - set the return code in case that it sets the syscall number to
        -1L

        It can even set it in case it sets it to some other value, but
        the architecture code has to be resilent against that no matter
        what.

      - if it does not set the return code when it sets the syscall
        number to -1L then it has a historical expectation that the
        syscall returns -ENOSYS

        That's how it is and you can argue in circles and it's not going
        away unless you have a great argument why you can break existing
        user space probes/bpf scripts.

So now please provide in coherent sentences the argument why this solves
anything:

> However, reading the syscall number from pt_regs only after
> syscall_enter_from_user_mode exits does.

If you can, which I doubt, then please send a patch [series] against:

   git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git entry/rework

with proper change logs explaining the superiour solution.

If not, please spare us the next set of incoherent "I wan't a pony"
mails.

Thanks,

        tglx