From: Steven Rostedt <rostedt@goodmis.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Ingo Molnar <mingo@kernel.org>, X86 ML <x86@kernel.org>,
Daniel Xu <dxu@dxuuu.xyz>,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
kuba@kernel.org, mingo@redhat.com, ast@kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>,
kernel-team@fb.com, yhs@fb.com, linux-ia64@vger.kernel.org,
Abhishek Sagar <sagar.abhishek@gmail.com>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>
Subject: Re: [PATCH -tip v8 11/13] x86/unwind: Recover kretprobe trampoline entry
Date: Tue, 6 Jul 2021 11:11:36 -0400 [thread overview]
Message-ID: <20210706111136.7c5e9843@oasis.local.home> (raw)
In-Reply-To: <YOQMV8uE/2bVkPOY@hirez.programming.kicks-ass.net>
On Tue, 6 Jul 2021 09:55:03 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> > But I'm not so sure how ftrace treat it. It seems that the return_to_handler()
> > doesn't care such case. (anyway, return_to_handler() does not return but jump
> > to the original call-site, in that case, the information will be lost.)
>
> I find it bothersome (OCD, sorry :-) that both return trampolines behave
> differently. Doubly so because I know people (Steve in particular) have
> been talking about unifying them.
They were developed separately, and designed differently with different
goals in mind. Yes, I want to unify them, but trying to get the
different goals together, compounded by the fact that almost every arch
also implemented them differently (in which case, we need to find a way
to do it one arch at a time), makes the process extremely frustrating.
>
> Steve, can you clarify the ftrace side here? Afaict return_to_handler()
> is similarly affected.
I'm not exactly sure what the issue is. As Masami stated, kretprobe
uses a ret to return to the calling function, but ftrace uses a jmp.
kretprobe return tracing is more complex than the function graph return
tracing is (which is one of the issues I need to overcome to unify
them), and when the function graph return trampoline was created, it
did things as simple as possible (and before ORC existed).
Is this something to worry about now, or should we look to fix his in
the unifying process?
-- Steve
next prev parent reply other threads:[~2021-07-06 15:11 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-18 7:05 [PATCH -tip v8 00/13] kprobes: Fix stacktrace with kretprobes on x86 Masami Hiramatsu
2021-06-18 7:05 ` [PATCH -tip v8 01/13] ia64: kprobes: Fix to pass correct trampoline address to the handler Masami Hiramatsu
2021-07-05 7:46 ` Ingo Molnar
2021-07-05 10:05 ` Masami Hiramatsu
2021-06-18 7:05 ` [PATCH -tip v8 02/13] kprobes: treewide: Replace arch_deref_entry_point() with dereference_symbol_descriptor() Masami Hiramatsu
2021-07-05 7:48 ` Ingo Molnar
2021-07-05 12:03 ` Masami Hiramatsu
2021-07-07 18:28 ` Andrii Nakryiko
2021-07-08 4:08 ` Masami Hiramatsu
2021-06-18 7:05 ` [PATCH -tip v8 03/13] kprobes: treewide: Remove trampoline_address from kretprobe_trampoline_handler() Masami Hiramatsu
2021-07-05 7:03 ` Ingo Molnar
2021-07-05 10:03 ` Masami Hiramatsu
2021-07-05 7:49 ` Ingo Molnar
2021-06-18 7:05 ` [PATCH -tip v8 04/13] kprobes: Add kretprobe_find_ret_addr() for searching return address Masami Hiramatsu
2021-07-05 7:42 ` Ingo Molnar
2021-07-05 14:11 ` Masami Hiramatsu
2021-06-18 7:06 ` [PATCH -tip v8 05/13] x86/kprobes: Add UNWIND_HINT_FUNC on kretprobe_trampoline code Masami Hiramatsu
2021-07-05 8:02 ` Ingo Molnar
2021-07-09 15:31 ` Masami Hiramatsu
2021-07-10 1:41 ` Masami Hiramatsu
2021-07-10 19:01 ` Josh Poimboeuf
2021-07-10 19:24 ` [PATCH 1/2] objtool: Add frame-pointer-specific function ignore Josh Poimboeuf
2021-07-11 1:16 ` Masami Hiramatsu
2021-07-29 2:31 ` Masami Hiramatsu
2021-07-10 19:25 ` [PATCH 2/2] objtool: Ignore unwind hints for ignored functions Josh Poimboeuf
2021-07-11 2:07 ` Masami Hiramatsu
2021-06-18 7:06 ` [PATCH -tip v8 06/13] ARC: Add instruction_pointer_set() API Masami Hiramatsu
2021-06-18 7:06 ` [PATCH -tip v8 07/13] ia64: " Masami Hiramatsu
2021-06-18 7:06 ` [PATCH -tip v8 08/13] arm: kprobes: Make a space for regs->ARM_pc at kretprobe_trampoline Masami Hiramatsu
2021-07-05 8:04 ` Ingo Molnar
2021-07-05 14:40 ` Masami Hiramatsu
2021-06-18 7:06 ` [PATCH -tip v8 09/13] kprobes: Enable stacktrace from pt_regs in kretprobe handler Masami Hiramatsu
2021-06-18 14:04 ` Josh Poimboeuf
2021-06-18 7:06 ` [PATCH -tip v8 10/13] x86/kprobes: Push a fake return address at kretprobe_trampoline Masami Hiramatsu
2021-07-05 8:17 ` Ingo Molnar
2021-07-09 14:55 ` Masami Hiramatsu
2021-06-18 7:07 ` [PATCH -tip v8 11/13] x86/unwind: Recover kretprobe trampoline entry Masami Hiramatsu
2021-07-05 11:36 ` Peter Zijlstra
2021-07-05 15:42 ` Masami Hiramatsu
2021-07-06 7:55 ` Peter Zijlstra
2021-07-06 15:11 ` Steven Rostedt [this message]
2021-07-07 8:20 ` Peter Zijlstra
2021-07-07 8:36 ` Peter Zijlstra
2021-07-07 10:15 ` Masami Hiramatsu
2021-07-07 10:20 ` Peter Zijlstra
2021-07-07 10:45 ` Masami Hiramatsu
2021-07-07 13:29 ` Masami Hiramatsu
2021-07-07 14:42 ` Matt Wu
2021-07-11 14:09 ` Masami Hiramatsu
2021-07-11 15:28 ` Matt Wu
2021-07-12 4:57 ` Masami Hiramatsu
2021-06-18 7:07 ` [PATCH -tip v8 12/13] tracing: Show kretprobe unknown indicator only for kretprobe_trampoline Masami Hiramatsu
2021-06-18 7:07 ` [PATCH -tip v8 13/13] x86/kprobes: Fixup return address in generic trampoline handler Masami Hiramatsu
2021-07-05 8:34 ` Ingo Molnar
2021-07-06 12:57 ` Masami Hiramatsu
2021-06-18 17:44 ` [PATCH -tip v8 00/13] kprobes: Fix stacktrace with kretprobes on x86 Andrii Nakryiko
2021-06-28 13:50 ` Masami Hiramatsu
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=20210706111136.7c5e9843@oasis.local.home \
--to=rostedt@goodmis.org \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=dxu@dxuuu.xyz \
--cc=jpoimboe@redhat.com \
--cc=kernel-team@fb.com \
--cc=kuba@kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sagar.abhishek@gmail.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yhs@fb.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 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).