From: "Dmitry V. Levin" <ldv@strace.io>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Renzo Davoli <renzo@cs.unibo.it>,
linux-kernel@vger.kernel.org,
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>,
strace-devel@lists.strace.io
Subject: Re: [PATCH v4 1/2] ptrace: add PTRACE_SET_SYSCALL_INFO syscall skipping support
Date: Thu, 9 Jul 2026 01:09:23 +0300 [thread overview]
Message-ID: <20260708220923.GA4523@strace.io> (raw)
In-Reply-To: <ak5wSDahPDYMGGdV@redhat.com>
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
next prev parent reply other threads:[~2026-07-08 22:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 9:06 [PATCH v4 0/2] PTRACE_SET_SYSCALL_INFO: add support for seccomp syscall skipping Renzo Davoli
2026-07-08 9:06 ` [PATCH v4 1/2] ptrace: add PTRACE_SET_SYSCALL_INFO syscall skipping support Renzo Davoli
2026-07-08 15:32 ` Dmitry V. Levin
2026-07-08 15:44 ` Oleg Nesterov
2026-07-08 22:09 ` Dmitry V. Levin [this message]
2026-07-09 6:07 ` Oleg Nesterov
2026-07-08 9:06 ` [PATCH v4 2/2] selftests/ptrace: add a test case for PTRACE_SET_SYSCALL_INFO syscall skipping Renzo Davoli
2026-07-08 9:57 ` Dmitry V. Levin
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=20260708220923.GA4523@strace.io \
--to=ldv@strace.io \
--cc=akpm@linux-foundation.org \
--cc=berardi.dav@gmail.com \
--cc=evgsyr@gmail.com \
--cc=legion@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=renzo@cs.unibo.it \
--cc=shuah@kernel.org \
--cc=strace-devel@lists.strace.io \
/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.