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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The patch references non-existent `tracing_multi` fields in `struct bpf_link_info` causing a build failure, and the corresponding kernel `.fill_link_info` callback is missing.
- [Medium] Dynamically allocated memory for `ids`, `addrs`, and `cookies` arrays is leaked if the subsequent `bpf_link_get_info_by_fd()` call fails.
--

commit 1c150871ddc705d0719c83498c9983e353211882
Author: Jiri Olsa <jolsa@kernel.org>

bpftool: Add tracing_multi link info output

This patch adds support to bpftool to display tracing_multi link details.
It updates both the JSON and plain text output formats to show attached
functions, addresses, and cookies.

> diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c
> index bdcd717b0348f..db780ee398206 100644
> --- a/tools/bpf/bpftool/link.c
> +++ b/tools/bpf/bpftool/link.c
[ ... ]
> @@ -1114,6 +1217,39 @@ static int do_show_link(int fd)
>  			goto again;
>  		}
>  	}
> +	if (info.type == BPF_LINK_TYPE_TRACING_MULTI &&
> +	    !info.tracing_multi.ids) {

[Severity: Medium]
Will this break the build? It appears the tracing_multi struct is missing
from the bpf_link_info union in include/uapi/linux/bpf.h.

Also, it seems the kernel side might be missing the .fill_link_info
callback in bpf_tracing_multi_link_lops (in kernel/trace/bpf_trace.c)
to export this data to userspace.

> +		count = info.tracing_multi.count;
> +		if (count) {
> +			ids = calloc(count, sizeof(__u32));
> +			if (!ids) {
> +				p_err("mem alloc failed");
> +				close(fd);
> +				return -ENOMEM;
> +			}
> +			info.tracing_multi.ids = ptr_to_u64(ids);
> +
> +			addrs = calloc(count, sizeof(__u64));
> +			if (!addrs) {
> +				p_err("mem alloc failed");
> +				free(ids);
> +				close(fd);
> +				return -ENOMEM;
> +			}
> +			info.tracing_multi.addrs = ptr_to_u64(addrs);
> +
> +			cookies = calloc(count, sizeof(__u64));
> +			if (!cookies) {
> +				p_err("mem alloc failed");
> +				free(addrs);
> +				free(ids);
> +				close(fd);
> +				return -ENOMEM;
> +			}
> +			info.tracing_multi.cookies = ptr_to_u64(cookies);
> +			goto again;

[Severity: Medium]
If the execution jumps to again: and the subsequent call to
bpf_link_get_info_by_fd() fails, does this leak the memory allocated
for ids, addrs, and cookies?

Looking at the error path earlier in 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;
	}

It returns immediately without freeing these arrays if the second
syscall fails (e.g., due to a concurrent increase in function count
or link destruction).

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