mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.
> > 
> >  
> > 
> >  ?
> >
>

      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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome