Re: [PATCHv2 bpf-next 2/3] selftests/bpf: Add tracing_multi link info tests

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The patch adds selftests for `tracing_multi` link info (`BPF_LINK_TYPE_TRACING_MULTI`), but the required kernel-side implementation is entirely missing.
- [Low] The patch references `info.tracing_multi` inside `struct bpf_link_info`, but this field does not exist in the UAPI headers.
--

commit 23bb30d6d6d285433f08e70bf1a166ecfd023a7d
Author: Jiri Olsa <jolsa@kernel.org>

selftests/bpf: Add tracing_multi link info tests
    
Adding tracing_multi link info tests that follow the kprobe_multi
and uprobe_multi tests logic.

> diff --git a/tools/testing/selftests/bpf/prog_tests/fill_link_info.c b/tools/testing/selftests/bpf/prog_tests/fill_link_info.c
> index f589eefbf9fbd..4d021e9b0129c 100644
> --- a/tools/testing/selftests/bpf/prog_tests/fill_link_info.c
> +++ b/tools/testing/selftests/bpf/prog_tests/fill_link_info.c
[ ... ]
> +static int verify_tracing_multi_link_info(int fd, const struct bpf_program *prog,
> +					  const struct tmulti_target *targets,
> +					  __u32 obj_id, bool has_cookies)
> +{
[ ... ]
> +	err = bpf_link_get_info_by_fd(fd, &info, &len);
> +	if (!ASSERT_OK(err, "bpf_link_get_info_by_fd"))
> +		return -1;
> +
> +	if (!ASSERT_EQ(info.type, BPF_LINK_TYPE_TRACING_MULTI, "info.type"))
> +		return -1;
> +
> +	ASSERT_EQ(info.tracing_multi.attach_type, attach_type, "info.tracing_multi.attach_type");

[Severity: Low]
Does the tracing_multi field exist in struct bpf_link_info within the UAPI
headers?

It doesn't seem to be present in include/uapi/linux/bpf.h yet, which would
cause a build failure here when accessing info.tracing_multi.attach_type.

> +	ASSERT_EQ(info.tracing_multi.count, TRACING_MULTI_CNT, "info.tracing_multi.count");

[Severity: Medium]
Is the kernel-side implementation for filling this link info missing?

Without a .fill_link_info callback defined in bpf_tracing_multi_link_lops in
kernel/trace/bpf_trace.c, bpf_link_get_info_by_fd() will leave the
tracing_multi struct zero-initialized, causing this assertion to fail.

[ ... ]
> +static void verify_tracing_multi_invalid_user_buffer(int fd, const struct tmulti_target *targets)
> +{
> +	__u32 ids[TRACING_MULTI_CNT] = {};
> +	struct bpf_link_info info;
> +	__u32 len = sizeof(info);
> +	int err, i;
> +
> +	/* Wrong info setup (ids != NULL and cnt == 0) -> EINVAL */
> +	memset(&info, 0, sizeof(info));
> +	info.tracing_multi.ids = ptr_to_u64(ids);
> +	err = bpf_link_get_info_by_fd(fd, &info, &len);
> +	ASSERT_EQ(err, -EINVAL, "tracing_multi.invalid_count");

[Severity: Medium]
Will this return the expected -EINVAL error?

Since the kernel doesn't appear to implement .fill_link_info for this link
type yet, the validation that would return -EINVAL won't execute, causing
this assertion to fail.

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