On Thu, Nov 6, 2025 at 4:30 AM Peter Zijlstra <[email protected]> wrote: > > On Mon, Nov 03, 2025 at 11:09:22PM +0100, Jiri Olsa wrote: > > Currently we don't get stack trace via ORC unwinder on top of fgraph exit > > handler. We can see that when generating stacktrace from kretprobe_multi > > bpf program which is based on fprobe/fgraph. > > > > The reason is that the ORC unwind code won't get pass the return_to_handler > > callback installed by fgraph return probe machinery. > > > > Solving this by creating stack frame in return_to_handler expected by > > ftrace_graph_ret_addr function to recover original return address and > > continue with the unwind. > > > > Also updating the pt_regs data with cs/flags/rsp which are needed for > > successful stack retrieval from ebpf bpf_get_stackid helper. > > - in get_perf_callchain we check user_mode(regs) so CS has to be set > > - in perf_callchain_kernel we call perf_hw_regs(regs), so EFLAGS/FIXED > > has to be unset > > > > Acked-by: Masami Hiramatsu (Google) <[email protected]> > > Signed-off-by: Jiri Olsa <[email protected]> > > --- > > arch/x86/include/asm/ftrace.h | 5 +++++ > > arch/x86/kernel/ftrace_64.S | 8 +++++++- > > include/linux/ftrace.h | 10 +++++++++- > > 3 files changed, 21 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h > > index 93156ac4ffe0..b08c95872eed 100644 > > --- a/arch/x86/include/asm/ftrace.h > > +++ b/arch/x86/include/asm/ftrace.h > > @@ -56,6 +56,11 @@ arch_ftrace_get_regs(struct ftrace_regs *fregs) > > return &arch_ftrace_regs(fregs)->regs; > > } > > > > +#define arch_ftrace_partial_regs(regs) do { \ > > + regs->flags &= ~X86_EFLAGS_FIXED; \ > > + regs->cs = __KERNEL_CS; \ > > +} while (0) > > I lost the plot. Why here and not in asm below?
It was discussed during v1/v2: Jiri: "Note I feel like it'd be better to set those directly in return_to_handler, but Steven suggested setting them later in kprobe_multi code path. " Masami: "Yeah, stacktrace is not always used from the return handler." If there are any improvements possible it can be a follow up.
