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.
> 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
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":
> 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.
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.
Quite the contrary there has been a long time (30 years at least)
expectation that the return value has been preset to -ENOSYS.
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
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
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.
Thanks,
tglx
---
Ignorance is bliss -- Thomas Gray, 1742
