From: Oleg Nesterov <oleg@redhat.com>
To: "Dmitry V. Levin" <ldv@strace.io>
Cc: Sven Schnelle <svens@linux.ibm.com>,
strace development discussions <strace-devel@lists.strace.io>,
linux-kernel@vger.kernel.org, Renzo Davoli <renzo@cs.unibo.it>,
Andrew Morton <akpm@linux-foundation.org>,
Shuah Khan <shuah@kernel.org>, Alexey Gladkov <legion@kernel.org>,
Eugene Syromyatnikov <evgsyr@gmail.com>,
Davide Berardi <berardi.dav@gmail.com>
Subject: Re: [PATCH v2 1/5] ptrace: PTRACE_SET_SYSCALL_INFO syscall skipping support
Date: Thu, 9 Jul 2026 15:47:03 +0200 [thread overview]
Message-ID: <ak-mVxCNBM27yUa9@redhat.com> (raw)
In-Reply-To: <20260709075923.GA16739@strace.io>
On 07/09, Dmitry V. Levin wrote:
>
> On Thu, Jul 09, 2026 at 09:04:34AM +0200, Sven Schnelle wrote:
> > Renzo Davoli <renzo@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.
next prev parent reply other threads:[~2026-07-09 13:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 10:50 [PATCH v2 0/5] ptrace_set_syscall_info: add support for seccomp syscall skipping and instruction pointer modification Renzo Davoli
2026-07-03 10:50 ` [PATCH v2 1/5] ptrace: PTRACE_SET_SYSCALL_INFO syscall skipping support Renzo Davoli
2026-07-03 10:58 ` Oleg Nesterov
2026-07-03 11:48 ` Oleg Nesterov
2026-07-09 7:04 ` Sven Schnelle
2026-07-09 7:59 ` Dmitry V. Levin
2026-07-09 13:47 ` Oleg Nesterov [this message]
2026-07-09 13:58 ` Oleg Nesterov
2026-07-03 10:50 ` [PATCH v2 2/5] selftests/ptrace: add a test case for PTRACE_SYSCALL_INFO syscall skipping Renzo Davoli
2026-07-03 10:50 ` [PATCH v2 3/5] asm/ptrace.h: add instruction_pointer_set Renzo Davoli
2026-07-03 10:50 ` [PATCH v2 4/5] ptrace: add PTRACE_SYSCALL_INFO_FLAG_SET_IP Renzo Davoli
2026-07-03 11:04 ` Oleg Nesterov
2026-07-03 15:01 ` Renzo Davoli
2026-07-03 15:54 ` Oleg Nesterov
2026-07-04 9:11 ` Renzo Davoli
2026-07-03 10:50 ` [PATCH v2 5/5] selftests/ptrace: add a test case for PTRACE_SYSCALL_INFO_FLAG_SET_IP Renzo Davoli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ak-mVxCNBM27yUa9@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=berardi.dav@gmail.com \
--cc=evgsyr@gmail.com \
--cc=ldv@strace.io \
--cc=legion@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=renzo@cs.unibo.it \
--cc=shuah@kernel.org \
--cc=strace-devel@lists.strace.io \
--cc=svens@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.