On Tue, Jul 14, 2026 at 09:29:13AM +0200, Michal Suchánek wrote: > 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,
Sorry, I got confused, and was looking at the previous revision of the patchset. In this revision I do not see any obvious problem that did not exist before. Thanks Michal
