>> Also, the Function Graph Tracer modifies the return address of a traced >> function to a return trampoline to gather tracing data on function return. >> Stack traces taken from that trampoline and functions it calls are >> unreliable as the original return address may not be available in >> that context. Mark the stack trace unreliable accordingly. >> >> Signed-off-by: Madhavan T. Venkataraman <madve...@linux.microsoft.com> >> --- >> arch/arm64/kernel/entry-ftrace.S | 12 +++++++ >> arch/arm64/kernel/stacktrace.c | 61 ++++++++++++++++++++++++++++++++ >> 2 files changed, 73 insertions(+) >> >> diff --git a/arch/arm64/kernel/entry-ftrace.S >> b/arch/arm64/kernel/entry-ftrace.S >> index b3e4f9a088b1..1f0714a50c71 100644 >> --- a/arch/arm64/kernel/entry-ftrace.S >> +++ b/arch/arm64/kernel/entry-ftrace.S >> @@ -86,6 +86,18 @@ SYM_CODE_START(ftrace_caller) >> b ftrace_common >> SYM_CODE_END(ftrace_caller) >> >> +/* >> + * A stack trace taken from anywhere in the FTRACE trampoline code should be >> + * considered unreliable as a tracer function (patched at ftrace_call) could >> + * potentially set pt_regs->pc and redirect execution to a function >> different >> + * than the traced function. E.g., livepatch. > > IIUC the issue here that we have two copies of the pc: one in the regs, > and one in a frame record, and so after the update to the regs, the > frame record is stale. > > This is something that we could fix by having > ftrace_instruction_pointer_set() set both. >
Yes. I will look at this. > However, as noted elsewhere there are other issues which mean we'd still > need special unwinding code for this. > The only other cases we have discussed are EL1 exceptions in the ftrace code and the return trampoline for function graph tracing. Is there any other case? Thanks. Madhavan
