On Tue, Jul 14, 2026 at 12:20:49AM +0200, Thomas Gleixner wrote: > On Mon, Jul 13 2026 at 10:44, Michal Suchánek wrote: > > On Sun, Jul 12, 2026 at 11:25:32PM +0200, Thomas Gleixner wrote: > >> The return values of syscall_enter_from_user_mode[_work]() are > >> non-intuitive. Both functions return the syscall number which should be > >> invoked by the architecture specific syscall entry code. The returned > >> number can be: > >> > >> - the unmodified syscall number which was handed in by the caller > >> > >> - a modified syscall number (ptrace, seccomp, trace/probe/bpf) > >> > >> That has an additional twist. If the return value is -1L then the caller is > >> not allowed to modify the return value as that indicates that the modifying > >> entity requests to abort the syscall and set the return value already. That > >> can obviously not be differentiated from a syscall which handed in -1 as > >> syscall number. > >> > >> The most trivial way to deal with that is: > >> > >> set_return_value(regs, -ENOSYS); > >> nr = syscall_enter_from_user_mode(regs, nr); > >> if (valid(nr)) > >> handle_syscall(regs, nr); > >> > >> That's what LOONGARCH, RISCV, and X86 do. But PowerPC and S390 do not > >> preset the return value, so when user space hands in -1 and there is > >> nothing setting the return value in the entry work code, then the syscall > >> is skipped but the return value is whatever random data has been in the > >> return value register. > > > > The reason why PowerPC and S390 do not preset the return value is that > > the return value uses the same register as the syscall number. There are > > apparently other architectures on which the return value overlaps with > > the arguments which also do not preset the return value for that reason. > > If they would use the generic entry the same problem would arise. > > That's an implementation choice of PPC/S390 as I explained before, which > could trivially be solved by having an explicit pt_regs->return_val > member, > > >> Change the return values of syscall_enter_from_user_mode[_work]() to > >> boolean and return false, when either ptrace or seccomp request to skip the > > > > There is a difference between seccomp and ptrace. > > > > When seccomp indicates to skip the syscall it has also set the syscall > > return value. > > > > However, when the syscall number is -1 and the return value is not > > preset that does not indicate anything. > > I agree it's an invalid syscall, but the current generic entry code made > the rightful assumption that returning -1L as the syscall number either > results in -ENOSYS or in the value which was set by one of the entry > mechanisms as that code originated from the x86 implementation.
You know, the world is not x86. For 20+ years that is not true. > > It's not the fault of that code that PPC and S390 converted their stuff > over without paying attention to that detail. So this is not generic entry but rather x86-like entry do I get it correct? > > > The return value can still hold garbage. ptrace does not have the > > ability to indicate that a syscall is to be skipped, at least on the > > entry trace. It needs to be skipped based on the syscall number being > > invalid. > > That's what I explained you before and you told me I'm all wrong. > > But that's moot as this latest version does not care anymore. The > architectures whixh preset the return value are correct under all > circumstances and PPC/S390 can keep their own world view. So do I get it that you do not care about breaking userspace then? Thanks Michal
