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

[sashiko-bot@kernel.org]

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?

> +		}
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629212208.895962-4-jolsa@kernel.org?part=1