Re: [patch 16/18] x86/entry: Get rid of the sys_ni_syscall() indirection

[Thomas Gleixner <tglx@kernel.org>]

On Fri, Oct 23 2026 at 15:09, Thomas Gleixner wrote:
> On Thu, Oct 22 2026 at 17:22, H. Peter Anvin wrote:
> Tired brain misread the test output:
>
> [RUN]   Running tests under ptrace: modifying the default return
> [RUN]       Checking system calls with msb = 0 (0x0)
> [OK]                x32 syscalls 0:-64..-2 returned -ENOSYS as expected
> [OK]                x32 syscall 0:-1 returned MODIFIED_BY_PTRACE as expected
> [OK]                x64 syscalls 0:-64..-1 returned -ENOSYS as expected
>
> But that's because the "-1" on x32 is actually 0xFFFFFFFF while on x64
> it's 0x7FFFFFFF.
>
> The whole mess comes from using -1 as indicator for syscall abort which
> is undistinguishable from a syscall(nr=-1).
>
> Bah. Let me restore this nonsense.

The real question is how we ended up there. By design or as an
implementation detail which got later set in stone and the selftest was
written to test the implementation instead of testing against a
specification.

I went back in history and in 2.6.12 the behavior was for both i386 and
x86_64:

  regs->ax = -ENOSYS;
  syscall_trace_enter();
  if (syscall_nr < MAX)
  	do_syscall();
  ....

IOW, a tracer modification of regs->ax is not overwritten when the
syscall number is out of range.

Between 2.6.19-rc2 and -rc3 x86_64 was changed to _always_ overwrite
regs->ax when the syscall number is out of range.

In the 3.8 merge window seccomp introduced the -1 == skip bogosity which
got fixed up and made "consistent" in several changes afterwards. Just
that it never reached a state of consistency due to the overloading.

So are we stuck with this behavior or do we sit down and define what the
correct behavior should be?

Thanks,

        tglx