[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250115173642.GA25129@strace.io>
Date: Wed, 15 Jan 2025 19:36:42 +0200
From: "Dmitry V. Levin" <ldv@...ace.io>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Alexey Gladkov <legion@...nel.org>,
Eugene Syromyatnikov <evgsyr@...il.com>,
Mike Frysinger <vapier@...too.org>,
Renzo Davoli <renzo@...unibo.it>,
Davide Berardi <berardi.dav@...il.com>,
strace-devel@...ts.strace.io, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org
Subject: Re: [PATCH v2 6/7] ptrace: introduce PTRACE_SET_SYSCALL_INFO request
On Wed, Jan 15, 2025 at 05:38:09PM +0100, Oleg Nesterov wrote:
[...]
> > + syscall_set_nr(child, regs, nr);
> > + /*
> > + * 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.
> > + */
> > + if (nr != -1)
> > + syscall_set_arguments(child, regs, args);
>
> Thanks, much better than I tried to suggest in my reply to V1.
>
> But may be
>
> if (syscall_get_nr() != -1)
> syscall_set_arguments(...);
>
> will look a bit more consistent?
I'm sorry, but I didn't follow. As we've just set the syscall number with
syscall_set_nr(), why would we want to call syscall_get_nr() right after
that to obtain the syscall number?
--
ldv
Powered by blists - more mailing lists