From: Paul Burton <paul.burton@mips.com>
To: "Dmitry V. Levin" <ldv@altlinux.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
James Hogan <jhogan@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
Elvira Khabirova <lineprinter@altlinux.org>,
Eugene Syromyatnikov <esyr@redhat.com>,
Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"strace-devel@lists.strace.io" <strace-devel@lists.strace.io>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 24/25] ptrace: add PTRACE_GET_SYSCALL_INFO request
Date: Mon, 10 Dec 2018 18:04:22 +0000 [thread overview]
Message-ID: <20181210180421.wq3ruldbpvu2jpfm@pburton-laptop> (raw)
In-Reply-To: <20181210160940.GF14149@altlinux.org>
Hi Dmitry,
On Mon, Dec 10, 2018 at 07:09:40PM +0300, Dmitry V. Levin wrote:
> We decided to add .frame_pointer to struct ptrace_syscall_info just for
> consistency with .instruction_pointer and .stack_pointer; I must have been
> misled by comments in asm-generic/ptrace.h into thinking that
> frame_pointer() is universally available across architectures.
Is it correct to say that you're using frame_pointer() purely on user
register state, not kernel?
If so then one option would be to define it for MIPS as something like:
static inline unsigned long frame_pointer(struct pt_regs *regs)
{
return regs->regs[30];
}
My concern with that though would be that providing frame_pointer()
unconditionally might mislead people into thinking that the kernel
always has frame pointers, when in reality current MIPS kernels never
do. In fact a comment in MIPS' asm/ptrace.h seems to suggest the lack of
frame_pointer() is intentional for exactly that reason:
> Don't use asm-generic/ptrace.h it defines FP accessors that don't make
> sense on MIPS. We rather want an error if they get invoked.
Looking across architectures though MIPS isn't going to be the only one
missing frame_pointer(). With a little grepping it appears that these
architectures provide frame_pointer():
arm
arm64
hexagon
nds32
powerpc
riscv
sparc
um
x86
That leaves a whole bunch of other architectures (16) which don't have
frame_pointer(), or at least not in a way that I could see at a glance.
> Unlike .instruction_pointer and .stack_pointer that are actually needed
> in strace, .frame_pointer is not used, so from strace PoV we don't really
> need it.
>
> So the question is, does anybody need a
> struct ptrace_syscall_info.frame_pointer?
>
> If yes, how can frame_pointer() be defined on MIPS?
> Or should we just forget about making sense of frame_pointer() and remove
> struct ptrace_syscall_info.frame_pointer from the proposed API?
So, along these lines my suggestion would be to avoid it if you don't
really need it anyway.
Thanks,
Paul
next prev parent reply other threads:[~2018-12-10 18:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-10 4:23 [PATCH v5 00/25] ptrace: add PTRACE_GET_SYSCALL_INFO request Dmitry V. Levin
2018-12-10 4:31 ` [PATCH v5 24/25] " Dmitry V. Levin
2018-12-10 14:11 ` Oleg Nesterov
[not found] ` <20181210141107.GB4177-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-12-10 16:21 ` Dmitry V. Levin
2018-12-11 15:29 ` Oleg Nesterov
[not found] ` <20181211152953.GA8504-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-12-11 16:23 ` Dmitry V. Levin
2018-12-11 20:27 ` Dmitry V. Levin
2018-12-12 18:00 ` Oleg Nesterov
2018-12-10 14:26 ` kbuild test robot
[not found] ` <201812102200.snodXJSH%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-12-10 16:09 ` Dmitry V. Levin
2018-12-10 18:04 ` Paul Burton [this message]
2018-12-10 21:04 ` Palmer Dabbelt
[not found] ` <20181210160940.GF14149-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
2018-12-10 19:38 ` Andy Lutomirski
2018-12-10 17:44 ` Kees Cook
2018-12-12 9:28 ` kbuild test robot
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=20181210180421.wq3ruldbpvu2jpfm@pburton-laptop \
--to=paul.burton@mips.com \
--cc=esyr@redhat.com \
--cc=jannh@google.com \
--cc=jhogan@kernel.org \
--cc=keescook@chromium.org \
--cc=ldv@altlinux.org \
--cc=lineprinter@altlinux.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=oleg@redhat.com \
--cc=ralf@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).