On 2018-11-03, Aleksa Sarai cyphar@cyphar.com wrote:
This is actually a general bug in ftrace as well, because (for instance) while the unwinder calls into ftrace_graph_ret_addr() while walking up the stack this isn't used to correct regs->ip in perf_callchain_kernel(). I think this is the cause of the bug in ftrace-graph (if you switch to the "frame" unwinder you might be able to see it more clearly) -- but when trying to fix it I'm having trouble figuring out what retp should be (stack_addr(regs) doesn't give the right result for some reason).
@Steven, @Masami: Can you verify whether this is an actual bug? The snippet is like (arch/x86/events/core.c):
void perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs) { /* ... */ if (perf_callchain_store(entry, regs->ip)) return; /* rest of unwind code */ }
And it seems to me that there's an ftrace_graph_ret_addr missing here (though I was having trouble figuring out what the right retp would be in this context -- both stack_addr(regs) and ®s->sp appear to be wrong when I was trying to get this to work with kretprobes -- while my patch worked with all other kretprobe_trampoline cases in the unwinder).
The same issue is present in __save_stack_trace (arch/x86/kernel/stacktrace.c). This is likely the only reason that -- as Steven said -- stacktraces wouldn't work with ftrace-graph (and thus with the refactor both of you are discussing).
Thanks.