[patch 4/4] entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution

[Michal Suchánek]

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