Re: [PATCHv3 bpf-next 3/3] bpftool: Add tracing_multi link info output

[Jiri Olsa <olsajiri@gmail.com>]

On Mon, Jun 29, 2026 at 04:05:27PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c
> > index bdcd717b0348..eb0ba9d71692 100644
> > --- a/tools/bpf/bpftool/link.c
> > +++ b/tools/bpf/bpftool/link.c
> > @@ -377,6 +377,25 @@ static __u64 *u64_to_arr(__u64 val)
> >  	return (__u64 *) u64_to_ptr(val);
> >  }
> >
> > +static __u32 *u64_to_u32_arr(__u64 val)
> > +{
> > +	return (__u32 *)u64_to_ptr(val);
> > +}
> > +
> > +static struct kernel_sym *find_kernel_sym_by_addr(__u64 addr, bool is_ibt_enabled)
> > +{
> > +	struct kernel_sym *sym;
> > +
> > +	if (!addr)
> > +		return NULL;
> > +
> > +	sym = kernel_syms_search(&dd, addr);
> > +	if (!sym && is_ibt_enabled && addr >= 4)
> > +		sym = kernel_syms_search(&dd, addr - 4);
> 
> When is_ibt_enabled is set, can addr ever be resolved by the first
> kernel_syms_search(&dd, addr) call, or does a match always require the
> addr - 4 adjustment?
> 
> If a match is only ever possible at addr - 4, would an if/else be clearer
> here than trying addr first and then falling back to addr - 4?

I see trace-able functions without endbr instruction at the entry
on kernel with IBT enabled, like:

	# cat available_filter_functions_addrs | grep get_next_root
	ffffffff81211a70 get_next_root
	# cat /proc/kallsyms | grep get_next_root
	ffffffff81211a70 t get_next_root

and having adjusted functions with endbr instruction as well:

	# cat available_filter_functions_addrs | grep ksys_read
	ffffffff816f6404 ksys_readahead
	ffffffff8182bf14 ksys_read
	# cat /proc/kallsyms | grep ksys_read
	ffffffff816f6400 T ksys_readahead
	ffffffff8182bf10 T ksys_read

so we need the check as is

jirka