On Wed, 15 Oct 2025 12:11:38 -0400 Steven Rostedt <[email protected]> wrote:
> > > Hmm, we do have a way to retrieve the actual return caller from a location
> > > for return_to_handler:
> > >
> > > See kernel/trace/fgraph.c: ftrace_graph_get_ret_stack()
> > >
> > > Hmm, I think the x86 ORC unwinder needs to use this.
> >
> > I'm confused, is that not what ftrace_graph_ret_addr() already does?
> Ah yeah, that does it too. I just searched for the first function that did
> the look up ;-)
> Now I guess the question is, why is this not working?
I've also encountered this issue recently. It only outputs the stack trace of
return_to_handler, for example:
# bpftrace -e 'kretprobe:vfs_rea* {@[kstack]=count()}'
Attaching 1 probe...
^C
@[
ksys_read+192
get_perf_callchain+211
bpf_get_stackid+101
cleanup_module+303100
kprobe_multi_link_prog_run+175
fprobe_return+265
__ftrace_return_to_handler.isra.0+433
return_to_handler+30
]: 1
The return stack trace when directly executing samples/fprobe/fprobe_example.c
is similar:
[ 71.892353] return_to_handler: kernel_thread+0x71/0xa0
[ 71.892356] sample_exit_handler: Return from <kernel_clone+0x4/0x470> ip =
0x000000000e0e2004 to rip = 0x00000000127e6d58 (kernel_thread+0x71/0xa0)
[ 71.892361] __ftrace_return_to_handler.isra.0+0x1b1/0x280
[ 71.892363] return_to_handler+0x1e/0x50
No cases were found where the ret of the ftrace_graph_ret_addr function is
equal to return_handler.
Additionally, I noticed that when the x86 architecture executes
perf_callchain_kernel, perf_hw_regs(regs) is false,
and it calls unwind_start(&state, current, NULL, (void *)regs->sp);
which then proceeds to __unwind_start where the check task == current is
performed.
However, the ARM architecture executes kunwind_init_from_regs(&state, regs);
instead of taking the second branch with the task == current check.
I hope these phenomena can help you analyze the cause of this issue.
Thanks.
