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

[Dmitry V. Levin]

On Wed, Jul 08, 2026 at 05:44:08PM +0200, Oleg Nesterov wrote:
> On 07/08, Dmitry V. Levin wrote:
> >
> > On Wed, Jul 08, 2026 at 11:06:54AM +0200, Renzo Davoli wrote:
> >
> > > System call suppression for PTRACE_SYSCALL_INFO_ENTRY is currently omitted
> > > because its implementation is architecture-dependent. On some architectures,
> > > the system call number and return value share the same register, making it
> > > difficult to suppress a system call without altering the return value. A
> > > portable implementation would require an audit of all supported architectures.
> >
> > I suggest the following wording for the explanation why
> > PTRACE_SYSCALL_INFO_ENTRY is not supported yet:
> >
> > System call suppression via PTRACE_SYSCALL_INFO_ENTRY is currently not
> > implemented.  On some architectures (e.g. MIPS), when a system call
> > is skipped by setting the syscall number to -1 at the entry stop, the
> > architecture entry path unconditionally overwrites the return value
> > register with -ENOSYS before the tracer can set a custom return value
> > at the exit stop.
> 
> Thanks! but looks a bit misleading or (quite possibly) I am confused...
> 
> At least for MIPS, I think it should something like
> 
> 	when a system call is skipped by setting the syscall number to -1
> 
> 	...
> 
> 	architecture entry path unconditionally overwrites the return value
> 	register with -ENOSYS
> 
> 	...
> 
> 	_after_ (or even if ) the tracer has already set a custom return value
> 
> No?

Sure, thanks for spotting.  Consider the following edition:

System call suppression via PTRACE_SYSCALL_INFO_ENTRY is currently not
implemented.  On some architectures (e.g. MIPS), when a system call is
skipped by setting the syscall number to -1 at the entry stop, the
architecture entry path unconditionally overwrites the return value
register with -ENOSYS, clobbering any custom return value set by the
tracer at the entry stop.


-- 
ldv