Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1247738 > unrolled thread

[PATCH] arm64: ftrace: function_graph: dump real return addr in call trace

Started byLi Bin <huawei.libin@huawei.com>
First post2015-10-15 14:20 +0200
Last post2015-10-15 16:20 +0200
Articles 4 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] arm64: ftrace: function_graph: dump real return addr in call trace Li Bin <huawei.libin@huawei.com> - 2015-10-15 14:20 +0200
    Re: [PATCH] arm64: ftrace: function_graph: dump real return addr in call trace Arnd Bergmann <arnd@arndb.de> - 2015-10-15 14:50 +0200
      Re: [PATCH] arm64: ftrace: function_graph: dump real return addr in  call trace Will Deacon <will.deacon@arm.com> - 2015-10-15 15:00 +0200
        Re: [PATCH] arm64: ftrace: function_graph: dump real return addr in  call trace Steven Rostedt <rostedt@goodmis.org> - 2015-10-15 16:20 +0200

#1247738 — [PATCH] arm64: ftrace: function_graph: dump real return addr in call trace

FromLi Bin <huawei.libin@huawei.com>
Date2015-10-15 14:20 +0200
Subject[PATCH] arm64: ftrace: function_graph: dump real return addr in call trace
Message-ID<qjPFL-68P-13@gated-at.bofh.it>
When using function graph tracer, the printed call trace will be as
following that has many ftrace_graph_caller (return_to_handler - 4),
which is been placed in the stack by ftrace_graph tracer to replace
the real return address.

    [  198.582568] Call trace:
    [  198.583313] [<ffffffc0002a1070>] next_tgid+0x30/0x100
    [  198.584359] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
    [  198.585503] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
    [  198.586574] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
    [  198.587660] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
    [  198.588896] Code: aa0003f5 2a0103f4 b4000102 91004043 (885f7c60)
    [  198.591092] ---[ end trace 6a346f8f20949ac8 ]---

This patch fix it, and dump the real return address in the call trace.

Signed-off-by: Li Bin <huawei.libin@huawei.com>
---
 arch/arm64/kernel/traps.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index f93aae5..4a4e679 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -143,9 +143,38 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
 	set_fs(fs);
 }
 
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+static void print_ftrace_graph_addr(unsigned long addr,
+					struct task_struct *tsk,
+					unsigned long sp, int *graph)
+{
+	unsigned long ret_addr;
+	int index = tsk->curr_ret_stack;
+
+	if (addr != ((unsigned long)return_to_handler - 4))
+		return;
+
+	if (!tsk->ret_stack || index < *graph)
+		return;
+
+	index -= *graph;
+	ret_addr = tsk->ret_stack[index].ret;
+
+	dump_backtrace_entry(ret_addr - 4, sp);
+
+	(*graph)++;
+}
+#else
+static inline void print_ftrace_graph_addr(unsigned long addr,
+					struct task_struct *tsk,
+					unsigned long sp, int *graph)
+{}
+#endif
+
 static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 {
 	struct stackframe frame;
+	int graph = 0;
 
 	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
 
@@ -177,7 +206,9 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 		ret = unwind_frame(&frame);
 		if (ret < 0)
 			break;
+
 		dump_backtrace_entry(where, frame.sp);
+		print_ftrace_graph_addr(where, tsk, frame.sp, &graph);
 	}
 }
 
-- 
1.7.12.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1247768

FromArnd Bergmann <arnd@arndb.de>
Date2015-10-15 14:50 +0200
Message-ID<qjQ8N-6Gn-3@gated-at.bofh.it>
In reply to#1247738
On Thursday 15 October 2015 20:12:35 Li Bin wrote:
> 
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> +static void print_ftrace_graph_addr(unsigned long addr,
> +                                       struct task_struct *tsk,
> +                                       unsigned long sp, int *graph)
> +{
> +       unsigned long ret_addr;
> +       int index = tsk->curr_ret_stack;
> +
> +       if (addr != ((unsigned long)return_to_handler - 4))
> +               return;
> +
> +       if (!tsk->ret_stack || index < *graph)
> 

I think it would be nicer to remove the #ifdef and write this as

static void print_ftrace_graph_addr(unsigned long addr,
                                    struct task_struct *tsk,
                                    unsigned long sp, int *graph)
{
       unsigned long ret_addr;
       int index = tsk->curr_ret_stack;

       if (!IS_ENABLED(CONFIG_FUNCTION_GRAPH_TRACER))
		return;

       if (addr != ((unsigned long)return_to_handler - 4))
               return;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1247777 — Re: [PATCH] arm64: ftrace: function_graph: dump real return addr in call trace

FromWill Deacon <will.deacon@arm.com>
Date2015-10-15 15:00 +0200
SubjectRe: [PATCH] arm64: ftrace: function_graph: dump real return addr in call trace
Message-ID<qjQit-6RK-9@gated-at.bofh.it>
In reply to#1247768
On Thu, Oct 15, 2015 at 02:46:16PM +0200, Arnd Bergmann wrote:
> On Thursday 15 October 2015 20:12:35 Li Bin wrote:
> > 
> > +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> > +static void print_ftrace_graph_addr(unsigned long addr,
> > +                                       struct task_struct *tsk,
> > +                                       unsigned long sp, int *graph)
> > +{
> > +       unsigned long ret_addr;
> > +       int index = tsk->curr_ret_stack;
> > +
> > +       if (addr != ((unsigned long)return_to_handler - 4))
> > +               return;
> > +
> > +       if (!tsk->ret_stack || index < *graph)
> > 
> 
> I think it would be nicer to remove the #ifdef and write this as
> 
> static void print_ftrace_graph_addr(unsigned long addr,
>                                     struct task_struct *tsk,
>                                     unsigned long sp, int *graph)
> {
>        unsigned long ret_addr;
>        int index = tsk->curr_ret_stack;
> 
>        if (!IS_ENABLED(CONFIG_FUNCTION_GRAPH_TRACER))
> 		return;
> 
>        if (addr != ((unsigned long)return_to_handler - 4))
>                return;

Is this the same old problem caused by e306dfd06fcb ("ARM64: unwind: Fix
PC calculation")? I've said previously that I'm happy to revert that if
we're the only architecture with this behaviour, but Akashi resisted
because there are other issues with ftrace that he was hoping to address
and they would resolve this too.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1247836 — Re: [PATCH] arm64: ftrace: function_graph: dump real return addr in call trace

FromSteven Rostedt <rostedt@goodmis.org>
Date2015-10-15 16:20 +0200
SubjectRe: [PATCH] arm64: ftrace: function_graph: dump real return addr in call trace
Message-ID<qjRxU-pn-9@gated-at.bofh.it>
In reply to#1247777
On Thu, 15 Oct 2015 13:51:33 +0100
Will Deacon <will.deacon@arm.com> wrote:

> Is this the same old problem caused by e306dfd06fcb ("ARM64: unwind: Fix
> PC calculation")? I've said previously that I'm happy to revert that if
> we're the only architecture with this behaviour, but Akashi resisted
> because there are other issues with ftrace that he was hoping to address
> and they would resolve this too.

Just a reference, but this patch is pretty much exactly what x86
currently has. I wonder if I should make that function generic for all
archs to use.

If you accept this patch, I can look at what archs do and pull out the
common code and place it into the core code and have the archs call
that instead.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web