Michal!
On Fri, Jul 10 2026 at 13:01, Michal Suchánek wrote:
> On Wed, Jul 08, 2026 at 10:34:38PM +0200, Thomas Gleixner wrote:
>> 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.
That does not solve anything at all.
TBH, your communication style is annoying as hell. You fail to provide
any useful arguments and explanations despite me giving you a proper
analysis. And I'm absolutely tired of this.
So let me try again for _ONE_ last time to explain you why your ppc/s390
world view is broken and let's look at the current code (irrelevant
portions omitted).
static __always_inline long syscall_trace_enter(struct pt_regs *regs, unsigned
long work)
{
if (work & SYSCALL_WORK_SYSCALL_USER_DISPATCH) {
#1 if (syscall_user_dispatch(regs))
return -1L;
}
if (work & (SYSCALL_WORK_SYSCALL_TRACE | SYSCALL_WORK_SYSCALL_EMU)) {
#2 ret = arch_ptrace_report_syscall_entry(regs);
if (ret || (work & SYSCALL_WORK_SYSCALL_EMU))
return -1L;
}
/* Do seccomp after ptrace, to catch any tracer changes. */
if (work & SYSCALL_WORK_SECCOMP) {
#3 ret = __secure_computing();
if (ret == -1L)
return ret;
}
/* Either of the above might have changed the syscall number */
#4 syscall = syscall_get_nr(current, regs);
if (unlikely(work & SYSCALL_WORK_SYSCALL_TRACEPOINT))
#5 syscall = trace_syscall_enter(regs, syscall);
return syscall;
}
#1) The user dispatch mechanism does not modify the syscall return
value, but it can rollback the syscall and tell the call site to
skip the invocation.
The mechanism used in upstream today is to return -1L as the syscall
number which makes the architecture specific entry code skip the
syscall and refrain from touching the return value.
#2) ptrace
ptrace can poke whatever it wants into the syscall number storage
via ptrace_set_syscall_info_entry() -> syscall_set_nr()
It does not set the return code.
It does not abort the syscall when the poked syscall number is -1L.
It only aborts when a fatal signal is pending.
#3) seccomp
seccomp reads the syscall number, which might have been modified by
ptrace and acts upon it.
It can rewrite the syscall number even if it is -1 to begin with.
It can rewrite the return code if it decides to refuse the syscall
to be executed.
If it refuses the syscall to be executed it returns -1L.
#4) Rereading the syscall number after ptrace/seccomp
That's required to give the eventually modified number to the
tracer.
Obviously the tracer could do that on it's own, but with the current
implementation it expects the eventually modified syscall number
Changing that to make the tracer do it, is possible but does not
change any of the actual expectations. That's just cosmetic wankery.
#5) tracing
tracing can have a probe or bpf attached, which in turn can
- rewrite the syscall number
- set the return code in case that it sets the syscall number to
-1L
It can even set it in case it sets it to some other value, but
the architecture code has to be resilent against that no matter
what.
- if it does not set the return code when it sets the syscall
number to -1L then it has a historical expectation that the
syscall returns -ENOSYS
That's how it is and you can argue in circles and it's not going
away unless you have a great argument why you can break existing
user space probes/bpf scripts.
So now please provide in coherent sentences the argument why this solves
anything:
> However, reading the syscall number from pt_regs only after
> syscall_enter_from_user_mode exits does.
If you can, which I doubt, then please send a patch [series] against:
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git entry/rework
with proper change logs explaining the superiour solution.
If not, please spare us the next set of incoherent "I wan't a pony"
mails.
Thanks,
tglx
