On Wed, Oct 23, 2024 at 12:50 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Sat, Oct 19, 2024 at 2:15 AM Xu Kuohai <xukuohai@xxxxxxxxxxxxxxx> wrote: > > > > From: Xu Kuohai <xukuohai@xxxxxxxxxx> > > > > The callsite layout for arm64 fentry is: > > > > mov x9, lr > > nop > > > > When a bpf prog is attached, the nop instruction is patched to a call > > to bpf trampoline: > > > > mov x9, lr > > bl <bpf trampoline> > > > > This passes two return addresses to bpf trampoline: the return address > > for the traced function/prog, stored in x9, and the return address for > > the bpf trampoline, stored in lr. To ensure stacktrace works properly, > > the bpf trampoline constructs two fake function stack frames using x9 > > and lr. > > > > However, struct_ops progs are used as function callbacks and are invoked > > directly, without x9 being set as the fentry callsite does. Therefore, > > only one stack frame should be constructed using lr for struct_ops. > > Are you saying that currently stack unwinder on arm64 is > completely broken for struct_ops progs ? > or it shows an extra frame that doesn't have to be shown ? > > If former then it's certainly a bpf tree material. > If latter then bpf-next will do. > Pls clarify. It is not completely broken, only an extra garbage frame is shown between the caller of the trampoline and its caller. So, this can go from the bpf-next tree. But let's wait for Xu to provide more information. Thanks, Puranjay
