On Wed, Jul 08, 2026 at 10:34:38PM +0200, Thomas Gleixner wrote:
> On Wed, Jul 08 2026 at 17:52, Michal Suchánek wrote:
> > On Tue, Jul 07, 2026 at 09:06:48PM +0200, Thomas Gleixner wrote:
> >> In preparation of converting the return value of
> >> syscall_enter_from_user_mode[_work]() bool, rework trace_syscall_enter() to
> >>
> >> - update the syscall number via a pointer argument
> >>
> >> - Return True if the syscall number is != -1, False otherwise
> >
> > This does not achieve the goal of the initial RFC: To detangle the
> > return value of syscall_enter_from_user_mode from the syscall number.
>
> As I explained to you before: Your RFC broke the implicit assumption of
> tracing, which is way worse than having this oddity.
It would be so nice to make the assumptions about the entry API explicit
so that platforms can agree on the semantics.
>
> > This still conflates them, making it impossible to tell if the syscall
> > was rejected or syscall number was -1 to start with. Now also obfuscated
> > by performing the check deeper inside the common code.
>
> That's where it belongs. It's a problem to solve within the given
> semantics of trace_syscall_enter() and not a problem to be worked around
> at the call sites if you want to have consolidated semantics.
>
> >> The only difference is that this also returns False, when the syscall
> >> number was already -1 to begin with, but there is not much which can be
> >> done about that. As the architecture has to preset the return value to
> >> -ENOSYS anyway, that results in the correct return value for such an
> >> invalid syscall.
> >
> > That's not possible to do for architectures where the syscall number and
> > the syscall return value are in the same register.
> >
> > You suggested that it is possible to not write the return value into an
> > actual register but use an additional field for that, and have the exit
> > code write the register.
> >
> > However, that's not what is documented, nor what is currently done.
>
> Just because S390 screwed up their ABI and then on top of that failed to
> do what _every_ other architecture in the kernel does, i.e. having a
> result storage which is preset to -ENOSYS does not mean that S390 did
> the right thing just because it was not documented. Kernel documentation
> is known to be incomplete and I fixed it up in the last patch as you
> might have noticed.
>
> Just for the record. Presetting the return value to -ENOSYS has been
> practice for three decades. I couldn't be bothered to do a full search
No, it isn't practice anymore for decades.
The moment ppc and s390 support was merged they do not preset the
syscall return value to -ENOSYS, for obvious reason.
That is how the undocumented, implicit, 'as implemented' API goes. It
silently changes as the implementation evolves.
> in the history trees to figure out the exact point, but as of 2.1.9,
> which was released in Nov. 1996, this is definitely the case.
>
> So don't tell me that because S390 missed the train when it was
> added to mainline in 2007 (, i.e. 11 years _after_ this "undocumented" rule
> was
> established that now 20 years later the world has to revolve around S390
> and your personal idea of "clear and intelligible":
Don't tell me you missed the train on what the actual API of syscall
entry is.
>
> > While this is an improvement in some respects the goal to have clear and
> > intelligible API around the generic entry is not acheived.
>
> I'm honestly not sure whether I should laugh or cry.
>
> You are completely missing the point:
>
> 1) The set in stone rule is that if the entry code returns -1L as the
> syscall number then the architecture code has to skip the syscall
> invocation _and_ is not supposed to change the return value.
Which stone?
Pics or it did not happen.
>
> 2) There is no guarantee and never has been that any of the involved
> mechanisms (ptrace, seccomp, tracing) will change the return value
> when it sets the syscall number to -1L.
For ptrace to correctly emulate a syscall it needs to set the syscall nr
to an invalid value on entry, and the desired result if the syscall on
exit AFAICT.
Relying on platfrom quirk to assume that the return valu is set to
ENOSYS is insufficient.
I doubt many platfroms have an ABI that dictates that the register that
has the syscal nr is set to -1 on exit from syscal. Then even if the
-ENOSYS is preset by the kernel the syscall nr needs to be poked back on
exit for the emulation to be correct.
>
> Quite the contrary there has been a long time (30 years at least)
> expectation that the return value has been preset to -ENOSYS.
That is your opinion, not the fact. Multiple platforms do not work like
that.
>
> 3) It's trivial as demonstrated to make ptrace and seccomp more
> comprehensible but that does not invalidate #2
>
> 4) Due to the historical integration of tracing (+probes/BPF) there is
> an implicit assumption that the return code is preset to -ENOSYS.
> See #2
False again
>
> 5) There is an obvious ambiguity between the initial syscall number
> being -1 and the change of syscall number to -1 in the case of
> tracing, but that's not unique to tracing:
>
> If e.g. seccomp() observes the handed in syscall number to be -1
> and tells in the return code to skip the syscall, then it can
> rightfully assume that the return code will be -ENOSYS and has no
> obligation to set it explicitly. See #2
False again
>
> Q: Is it perfect?
> A: No
>
> Q: Can it be made perfect?
> A: No, because you can't change history and established practice.
>
> Just for illustration. Changing the logic in trace_syscall_enter() to:
>
> --- a/kernel/entry/syscall-common.c
> +++ b/kernel/entry/syscall-common.c
> @@ -9,13 +9,15 @@
>
> bool trace_syscall_enter(struct pt_regs *regs, long *syscall)
> {
> + long orig_syscall = *syscall;
> +
> trace_sys_enter(regs, *syscall);
> /*
> * Probes or BPF hooks in the tracepoint may have changed the
> * system call number. Reread it.
> */
> *syscall = syscall_get_nr(current, regs);
> - return *syscall != -1L;
> + return *syscall == orig_syscall || *syscall != -1L;
> }
>
> void trace_syscall_exit(struct pt_regs *regs, long ret)
>
> does not make #2 magically go away. It's still the same problem whether
> you like it or not.
However, reading the syscall number from pt_regs only after
syscall_enter_from_user_mode exits does.
Thanks
Michal
