On Tue, Aug 02, 2016 at 10:30:11PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 20:56:56 -0500 > Josh Poimboeuf <jpoim...@redhat.com> wrote: > > > It's not specific to NMIs. The problem is that dump_trace() is starting > > from the frame pointed to by a pt_regs, rather than the current frame. > > Instead of starting with the current frame, the first 10 functions on > > the stack are skipped by the unwinder, but they're *not* skipped on the > > ret_stack. So it starts out out-of-sync. > > OK, I see what you mean. If we do a dumpstack from interrupt passing in > the pt_regs of the kernel thread that was interrupted, even though > functions up to the interrupt was called and traced, which will show up > in the dump stack that shouldn't. > > OK, you convinced me. Add the extra pointer, then we will have 4 longs > and 2 long longs in ftrace_ret_stack. That's not that bad.
Hm, since 'fp' is only used for mcount, I guess we could avoid allocating it for fentry? That would save a long when a modern compiler is used. Like: diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h index 1e814ae..fc508a7 100644 --- a/include/linux/ftrace.h +++ b/include/linux/ftrace.h @@ -795,7 +795,9 @@ struct ftrace_ret_stack { unsigned long func; unsigned long long calltime; unsigned long long subtime; +#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY) unsigned long fp; +#endif }; /* diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c index 9caa9b2..86b2719 100644 --- a/kernel/trace/trace_functions_graph.c +++ b/kernel/trace/trace_functions_graph.c @@ -171,7 +171,9 @@ ftrace_push_return_trace(unsigned long ret, unsigned long func, int *depth, current->ret_stack[index].func = func; current->ret_stack[index].calltime = calltime; current->ret_stack[index].subtime = 0; +#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && !defined(CC_USING_FENTRY) current->ret_stack[index].fp = frame_pointer; +#endif *depth = current->curr_ret_stack; return 0;