Re: [RFC PATCH bpf-next 12/12] selftests/bpf: Test attaching struct_ops to a cgroup

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The return values of `bpf_map_get_info_by_fd()` are not checked, and the `info` struct and `info_len` parameter are reused across successive calls without being reset.
--

commit 7b32bddd7d98a92b1f824ecda2b3ef053e323da3
Author: Martin KaFai Lau <martin.lau@kernel.org>
Date:   Tue May 19 21:58:19 2026 +0000

selftests/bpf: Test attaching struct_ops to a cgroup

Basic tests for attaching struct_ops to cgroup.

> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_tcp_ops.c b/tools/testing/selftests/bpf/prog_tests/bpf_tcp_ops.c
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_tcp_ops.c

[ ... ]

> +static void test_query(int cgroup_fd, struct bpf_tcp_ops *skel)
> +{
> +	struct bpf_map_info info = {};
> +	__u32 info_len = sizeof(info);
> +	LIBBPF_OPTS(bpf_prog_query_opts, query_opts);
> +	struct bpf_link *link1 = NULL, *link2 = NULL;
> +	__u32 map1_id, map2_id, map_ids[2] = {};
> +	__s32 type_id;
> +
> +	type_id = get_bpf_tcp_ops_type_id();
> +	if (type_id <= 0)
> +		return;
> +
> +	bpf_map_get_info_by_fd(bpf_map__fd(skel->maps.tcp_ops1), &info, &info_len);
> +	map1_id = info.id;
> +
> +	bpf_map_get_info_by_fd(bpf_map__fd(skel->maps.tcp_ops2), &info, &info_len);
> +	map2_id = info.id;

[Severity: Medium]
Are the return values of bpf_map_get_info_by_fd() intentionally left
unchecked? If the function fails, it might lead to confusing test failures.

Additionally, does reusing the info struct and info_len between the two calls
without resetting them pose a risk? 

The kernel updates info_len during the first call, so reusing it could be
problematic if sizes differ. Also, if the second call were to fail, info.id
would retain the value from the first call, causing map2_id to incorrectly
equal map1_id.

Would it be better to wrap these calls in the standard assert macros and reset
the variables before the second call?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519215841.2984970-1-martin.lau@linux.dev?part=12