From: jeff.xie@linux.dev
To: "Steven Rostedt" <rostedt@goodmis.org>
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
xiehuan09@gmail.com, dolinux.peng@gmail.com,
chensong_2000@189.cn
Subject: Re: [PATCH v3] ftrace: Get the true parent ip for function tracer
Date: Tue, 08 Oct 2024 02:17:57 +0000 [thread overview]
Message-ID: <5bc5b9b07d997e299b048005826bc6d592265c67@linux.dev> (raw)
In-Reply-To: <20241007171027.629bdafd@gandalf.local.home>
October 8, 2024 at 5:10 AM, "Steven Rostedt" <rostedt@goodmis.org> wrote:
>
> On Sat, 5 Oct 2024 10:13:20 -0400
>
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> >
> > The crash happened here:
> >
>
> This has been bothering me all weekend so I dug more into it.
>
> The reason it was bothering me is because we use current later on, and it
>
> has no issue. But then I noticed the real bug!
>
> I was confused because the crashed instruction pointer was in the
>
> get_current() code. But that's not where the crash actually happened.
>
> >
> > static __always_inline unsigned long
> >
> > function_get_true_parent_ip(unsigned long parent_ip, struct ftrace_regs *fregs)
> >
> > {
> >
> > unsigned long true_parent_ip;
> >
> > int idx = 0;
> >
> >
> >
> > true_parent_ip = parent_ip;
> >
> > if (unlikely(parent_ip == (unsigned long)&return_to_handler))
> >
> > true_parent_ip = ftrace_graph_ret_addr(current, &idx, parent_ip, <<<----- CRASH
> >
>
> That's not the crash
>
> >
> > (unsigned long *)fregs->regs.sp);
> >
>
> The above is!
>
> fregs should *NEVER* be used directly. OK, I need to make:
>
> struct ftrace_regs {
>
> void *nothing_here[];
>
> };
>
> Now, to stop bugs like this.
>
> fregs is unique by architecture, and may not even be defined! That is, it
>
> can pass NULL for fregs. And only x86 has fregs->regs available. Other
>
> archs do not.
Thanks, I just saw this comment from include/linux/ftrace.h
* NOTE: user *must not* access regs directly, only do it via APIs, because
* the member can be changed according to the architecture.
*/
struct ftrace_regs {
struct pt_regs regs;
};
>
> You must use the fregs helper functions, thus the above can be:
>
> static __always_inline unsigned long
>
> function_get_true_parent_ip(unsigned long parent_ip, struct ftrace_regs *fregs)
>
> {
>
> unsigned long true_parent_ip;
>
> int idx = 0;
>
> true_parent_ip = parent_ip;
>
> if (unlikely(parent_ip == (unsigned long)&return_to_handler) && fregs)
>
> true_parent_ip = ftrace_graph_ret_addr(current, &idx, parent_ip,
>
> (unsigned long *)ftrace_regs_get_stack_pointer(fregs));
>
> return true_parent_ip;
>
> }
>
> So you can make a v5 with this update. And I'll go and make the empty
>
> ftrace_regs structure.
Thanks, I will update the patch.
>
> Thanks!
>
> -- Steve
>
> >
> > return true_parent_ip;
> >
> > }
> >
> >
> >
> > It appears that on some archs (x86 32 bit) the function tracer can be
> >
> > called when "current" is not set up yet, and can crash when accessing it.
> >
> >
> >
> > So perhaps we need to add:
> >
> >
> >
> > #ifdef CONFIG_ARCH_WANTS_NO_INSTR
> >
> > static __always_inline unsigned long
> >
> > function_get_true_parent_ip(unsigned long parent_ip, struct ftrace_regs *fregs)
> >
> > {
> >
> > unsigned long true_parent_ip;
> >
> > int idx = 0;
> >
> >
> >
> > true_parent_ip = parent_ip;
> >
> > if (unlikely(parent_ip == (unsigned long)&return_to_handler))
> >
> > true_parent_ip = ftrace_graph_ret_addr(current, &idx, parent_ip, <<<----- CRASH
> >
> > (unsigned long *)fregs->regs.sp);
> >
> > return true_parent_ip;
> >
> > }
> >
> > #else
> >
> > # define function_get_true_parent_ip(parent_ip, fregs) parent_ip
> >
> > #endif
> >
> >
> >
> > That is, if the arch has noinstr implemented, it should always be safe
> >
> > to access current, but if not, then there's no guarantee.
> >
> >
> >
> > ?
> >
>
prev parent reply other threads:[~2024-10-08 2:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 13:36 [PATCH v3] ftrace: Get the true parent ip for function tracer Jeff Xie
2024-10-02 14:55 ` jeff.xie
2024-10-02 15:14 ` Steven Rostedt
2024-10-05 14:13 ` Steven Rostedt
2024-10-06 3:28 ` jeff.xie
2024-10-07 21:10 ` Steven Rostedt
2024-10-08 2:17 ` jeff.xie [this message]
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=5bc5b9b07d997e299b048005826bc6d592265c67@linux.dev \
--to=jeff.xie@linux.dev \
--cc=chensong_2000@189.cn \
--cc=dolinux.peng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=xiehuan09@gmail.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.