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

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

[Li Bin]

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

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

[Arnd Bergmann]

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;

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

[Will Deacon]

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

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

[Steven Rostedt]

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

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

[Catalin Marinas]

On Thu, Oct 15, 2015 at 10:18:12AM -0400, Steven Rostedt wrote:
> 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.

The difference I see from the sh and x86 version is that we have this -4
on arm64, introduced by e306dfd06fcb as Will mentioned above (it seemed
to have caused more problems that it solved). I think we should revert
that commit first just to be in line with other architectures and then
apply additional fixes as needed.

Question for Li Bin: is your patch still needed if we revert commit
e306dfd06fcb?

Thanks.

-- 
Catalin

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

[libin]

在 2015/10/20 23:32, Catalin Marinas 写道:
> On Thu, Oct 15, 2015 at 10:18:12AM -0400, Steven Rostedt wrote:
>> 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.
>
> The difference I see from the sh and x86 version is that we have this -4
> on arm64, introduced by e306dfd06fcb as Will mentioned above (it seemed
> to have caused more problems that it solved). I think we should revert
> that commit first just to be in line with other architectures and then
> apply additional fixes as needed.
>
> Question for Li Bin: is your patch still needed if we revert commit
> e306dfd06fcb?
>

It still be needed, but it can be implemented in generic for all archs
as Steve suggested.

Thanks,
Li Bin

> Thanks.
>

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

[Steven Rostedt]

On Thu, 22 Oct 2015 08:55:43 +0800
libin <huawei.libin@huawei.com> wrote:


> It still be needed, but it can be implemented in generic for all archs
> as Steve suggested.

I still recommend implementing it for arm64 as well, and then we can
look at what was done and how we can make it all generic.

-- Steve

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

[Will Deacon]

On Thu, Oct 22, 2015 at 08:55:43AM +0800, libin wrote:
> 在 2015/10/20 23:32, Catalin Marinas 写道:
> >On Thu, Oct 15, 2015 at 10:18:12AM -0400, Steven Rostedt wrote:
> >>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.
> >
> >The difference I see from the sh and x86 version is that we have this -4
> >on arm64, introduced by e306dfd06fcb as Will mentioned above (it seemed
> >to have caused more problems that it solved). I think we should revert
> >that commit first just to be in line with other architectures and then
> >apply additional fixes as needed.
> >
> >Question for Li Bin: is your patch still needed if we revert commit
> >e306dfd06fcb?
> >
> 
> It still be needed, but it can be implemented in generic for all archs
> as Steve suggested.

Well, there's still an argument for reverting e306dfd06fcb because it
makes us behave differently to other architectures (in particular,
arch/arm).

Will