On Wed, Mar 20, 2024 at 11:55 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Wed, Mar 20, 2024 at 1:06 PM Andrii Nakryiko <andrii@xxxxxxxxxx> wrote: > > > > Dump of assembler code for function kprobe_multi_link_exit_handler: > > 0xffffffff8122f1e0 <+0>: add $0xffffffffffffffc0,%rdi > > 0xffffffff8122f1e4 <+4>: mov %rcx,%rdx > > 0xffffffff8122f1e7 <+7>: jmp 0xffffffff81230080 <kprobe_multi_link_prog_run> > > > > This means that when trying to capture LBR that traces all indirect branches > > we are wasting an entry just to record that kprobe_multi_link_exit_handler > > called/jumped into kprobe_multi_link_prog_run. > > I don't follow. > If LBR was configured to trace indirect branches then this direct jmp > shouldn't be recorded. > If LBR is capturing stack frames (those should be call/ret instructions) > then this jmp also won't be recorded. > If LBR is actually capturing all indirect, direct and conditional > jmps, and calls then saving an entry won't make a difference. > > Maybe it's an LBR configuration issue on the retsnoop side? furthermore. This 'jmp kprobe_multi_link_prog_run' is not any different than "goto" in C code and other unconditional jmp-s within functions. Something doesn't add up that this particular jmp stands out from other similar jmps before and after. From cpu pov the tail call jmp is the same as jmp within a function.
