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

[Oleg Nesterov]

Ah, I just noticed that Thomas wasn't CC'ed... Let me add him and resend
my email.

On 07/09, Dmitry V. Levin wrote:
>
> On Thu, Jul 09, 2026 at 09:04:34AM +0200, Sven Schnelle wrote:
> > Renzo Davoli <renzo at cs.unibo.it> writes:
> >
> > > This patch extends PTRACE_SET_SYSCALL_INFO with support for skipping a system
> > > call triggered via seccomp.
> > >
> > > When the tracer retrieves a ptrace_syscall_info structure with
> > > op == PTRACE_SYSCALL_INFO_SECCOMP, it may choose to skip the system
> > > call by changing op to PTRACE_SYSCALL_INFO_EXIT and
> > > populating the exit union fields (rval and is_error) to define
> > > the return value and error status for the tracee.
> >
> > Is it possible to indicate the information whether the syscall should be
> > skipped via a dedicated return value?
>
> Currently, there is no API for that, so everybody has been using -1 for
> that purpose.
>
> > There's currently work going on[1]
> > to do this for seccomp, and it would be awkward if ptrace introduces
> > this at the same time.
>
> If someday there would be a better API for that, ptrace could be able to
> use it as well.

Agreed, but...

This probably needs another discussion, but so far (rightly or not)
I don't think this needs any changes in ptrace paths.

IOW. If debugger does set_syscall_nr(-1) the syscall should be skipped.
And it will be skipped.

Yes, ptrace_report_syscall() doesn't return false in this case, but IMO
we do not care (at least in the context of this discussion).

Yes, this means that in this case syscall_trace_enter() (at least in
include/linux/entry-common.h) will still call trace_syscall_enter() and
syscall_enter_audit() but I see nothing wrong with that. In fact, right
now I think we should not change this behaviour.

Now back to the problem. Please see

	[patch 00/18] entry: Consolidate and rework syscall entry handling
	https://lore.kernel.org/all/20260707181957.433213175@kernel.org/

In particular, let me quote the note from

	https://lore.kernel.org/all/87se5tqkyp.ffs@fw13/

	Presetting the return value to -ENOSYS has been practice for three decades.

	...

	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.

I agree. And to me this means that arch/mips is simply wrong (even if this
arch doesn't use entry-common afaics) and it should be fixed.

Oleg.