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

[Jiri Olsa <olsajiri@gmail.com>]

On Mon, Jun 29, 2026 at 09:33:29PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Medium] bpftool uses a non-existent `tracing_multi` union member in `struct bpf_link_info`.
> - [Medium] The kernel-side `bpf_tracing_multi_link_lops` is missing the `.fill_link_info` callback.
> - [Low] Memory allocated for `ids`, `addrs`, and `cookies` is leaked on the error path of the `bpf_link_get_info_by_fd` syscall.
> --
> 
> commit 3c4bad76286f49adf87a7b01dc7042ac6368c5ce
> Author: Jiri Olsa <jolsa@kernel.org>
> 
> bpftool: Add tracing_multi link info output
> 
> Adding bpftool support to show tracing_multi link details. The new output will
> display attach types, counts, BTF IDs, addresses, cookies, and functions.
> 
> > diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c
> > index bdcd717b0348f..088d1d206065f 100644
> > --- a/tools/bpf/bpftool/link.c
> > +++ b/tools/bpf/bpftool/link.c
> 
> [ ... ]
> 
> > @@ -403,6 +422,52 @@ show_uprobe_multi_json(struct bpf_link_info *info, json_writer_t *wtr)
> >  	jsonw_end_array(json_wtr);
> >  }
> >  
> > +static void
> > +show_tracing_multi_json(struct bpf_link_info *info, json_writer_t *wtr)
> > +{
> > +	bool is_ibt_enabled = is_x86_ibt_enabled(), show_symbol;
> > +	__u64 *addrs, *cookies;
> > +	__u32 i, *ids;
> > +
> > +	if (!dd.sym_count)
> > +		kernel_syms_load(&dd);
> > +	show_symbol = !!dd.sym_count;
> > +
> > +	show_link_attach_type_json(info->tracing_multi.attach_type, wtr);
> 
> [Severity: Medium]
> Does `struct bpf_link_info` in `include/uapi/linux/bpf.h` include a
> `tracing_multi` member?
> 
> It looks like the `tracing_multi` struct is missing from `struct bpf_link_info`
> in the UAPI, which causes a compile error here when trying to access
> `info->tracing_multi.attach_type`.
> 
> Additionally, the kernel-side implementation in `kernel/trace/bpf_trace.c`
> appears to be missing the `.fill_link_info` callback in
> `bpf_tracing_multi_link_lops`.
> 
> Without it, will the kernel silently return unpopulated link details when
> queried via `bpf_obj_get_info_by_fd()`?
> 
> [ ... ]
> 
> > @@ -1114,6 +1226,26 @@ static int do_show_link(int fd)
> >  			goto again;
> >  		}
> >  	}
> > +	if (info.type == BPF_LINK_TYPE_TRACING_MULTI && !info.tracing_multi.ids) {
> > +		count = info.tracing_multi.count;
> > +		if (count) {
> > +			ids = calloc(count, sizeof(__u32));
> > +			addrs = calloc(count, sizeof(__u64));
> > +			cookies = calloc(count, sizeof(__u64));
> > +			if (!ids || !addrs || !cookies) {
> > +				p_err("mem alloc failed");
> > +				close(fd);
> > +				free(cookies);
> > +				free(addrs);
> > +				free(ids);
> > +				return -ENOMEM;
> > +			}
> > +			info.tracing_multi.ids = ptr_to_u64(ids);
> > +			info.tracing_multi.addrs = ptr_to_u64(addrs);
> > +			info.tracing_multi.cookies = ptr_to_u64(cookies);
> > +			goto again;
> 
> [Severity: Low]
> Do we leak the memory allocated for `ids`, `addrs`, and `cookies` if the
> subsequent `bpf_link_get_info_by_fd()` syscall fails?
> 
> When jumping to `again:`, if `bpf_link_get_info_by_fd()` returns an error, the
> function returns early without freeing these arrays:
> 
> tools/bpf/bpftool/link.c:do_show_link() {
>     ...
>     again:
> 	err = bpf_link_get_info_by_fd(fd, &info, &len);
> 	if (err) {
> 		p_err("can't get link info: %s",
> 		      strerror(errno));
> 		close(fd);
> 		return err;
> 	}
>     ...
> }
> 
> Should the error path free these arrays before returning?

right, that's pre-existing issue, I think we could do something like
below.. will send a separate fix

jirka


---
diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c
index 088d1d206065..3f5b3b12a404 100644
--- a/tools/bpf/bpftool/link.c
+++ b/tools/bpf/bpftool/link.c
@@ -1156,8 +1156,7 @@ static int do_show_link(int fd)
 	if (err) {
 		p_err("can't get link info: %s",
 		      strerror(errno));
-		close(fd);
-		return err;
+		goto out;
 	}
 	if (info.type == BPF_LINK_TYPE_RAW_TRACEPOINT &&
 	    !info.raw_tracepoint.tp_name) {
@@ -1281,13 +1280,14 @@ static int do_show_link(int fd)
 	else
 		show_link_close_plain(fd, &info);
 
+out:
 	free(ref_ctr_offsets);
 	free(cookies);
 	free(offsets);
 	free(addrs);
 	free(ids);
 	close(fd);
-	return 0;
+	return err;
 }
 
 static int do_show(int argc, char **argv)