Re: [PATCH v2 1/2] ptrace: PTRACE_SET_SYSCALL_INFO syscall skipping support

["Dmitry V. Levin" <ldv@strace.io>]

On Sun, Jul 05, 2026 at 08:41:07AM +0200, Renzo Davoli wrote:
[...]
> Moreover, kernel/ptrace.c contains the following comment:
> /*
>  * If the syscall number is set to -1, setting syscall arguments is not
>  * just pointless, it would also clobber the syscall return value on
>  * those architectures that share the same register both for the first
>  * argument of syscall and its return value.
>  */

I wrote this comment to warn explicitly against invoking
syscall_set_arguments() after syscall_set_nr(-1).  Doing so is unsafe on
several architectures, as setting the first syscall argument will clobber
the syscall return value on those platforms.

[...]
> By contrast, for PTRACE_SYSCALL syscall-entry stops, the man page only states
> that the tracer may modify the system call number. It does not specify that
> assigning a negative value must suppress the system call and preserve the
> return value across all architectures, even though many architectures implement
> exactly this behavior.

While setting the system call number to an invalid value during a
syscall-entry stop indeed suppresses the system call on all architectures,
the return value semantics are complicated.

The return value is normally set to -ENOSYS, but there are architectures
(parisc between commits v4.6-rc2~20^2 and v5.0-rc8~9^2~1, and riscv
since commit v6.5-rc7~13^2~5) where -ENOSYS isn't set.  Furthermore,
setting the return value along with the system call number during
a syscall-entry stop is not guaranteed to be honored on all architectures,
with MIPS being a notable example.

The man page could definitely be improved in this respect.


-- 
ldv