On October 23, 2026 7:24:22 AM PDT, Thomas Gleixner <[email protected]> wrote: >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 > >
Going back on something from 3.8 that is actively used seems unwise. I fear that that ship sailed a long time ago, even though I hate it just as much as you do.
