Re: [PATCH bpf-next v12 10/10] selftests/bpf: Verify bpf_iter for global percpu data

[bot+bpf-ci@kernel.org]

[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]

> diff --git a/tools/testing/selftests/bpf/prog_tests/global_data_init.c b/tools/testing/selftests/bpf/prog_tests/global_data_init.c
> index d308ca3b30457..7d6bda9092954 100644
> --- a/tools/testing/selftests/bpf/prog_tests/global_data_init.c
> +++ b/tools/testing/selftests/bpf/prog_tests/global_data_init.c
> @@ -327,6 +327,56 @@ static void test_global_percpu_data_verifier_log(void)
>  	RUN_TESTS(test_global_percpu_data);
>  }
>
> +static void test_global_percpu_data_iter(void)
> +{
> +	DECLARE_LIBBPF_OPTS(bpf_iter_attach_opts, opts);
> +	struct test_global_percpu_data *skel;
> +	union bpf_iter_link_info linfo = {};
> +	struct bpf_link *link = NULL;
> +	int fd, num_cpus, len, err;
> +	char buf[16];
> +
> +	num_cpus = libbpf_num_possible_cpus();
> +	if (!ASSERT_GT(num_cpus, 0, "libbpf_num_possible_cpus"))
> +		return;
> +
> +	skel = test_global_percpu_data__open();
> +	if (!ASSERT_OK_PTR(skel, "test_global_percpu_data__open"))
> +		return;
> +
> +	skel->rodata->num_cpus = num_cpus;
> +	skel->rodata->offsetof_num = offsetof(struct test_global_percpu_data__percpu, struct_data);
> +	skel->rodata->offsetof_num += sizeof(skel->percpu->struct_data) - sizeof(int);

This isn't a bug, but could these two lines collapse into a single
offsetof(struct test_global_percpu_data__percpu, struct_data.nums[6]),
so the offset names the field being read instead of depending on nums[6]
staying last in the struct?

> +	skel->rodata->elem_sz = roundup(sizeof(struct test_global_percpu_data__percpu), 8);
> +	skel->percpu->struct_data.nums[6] = 0xc0de;
> +
> +	err = test_global_percpu_data__load(skel);
> +	if (!ASSERT_OK(err, "test_global_percpu_data__load"))
> +		goto out;
> +
> +	linfo.map.map_fd = bpf_map__fd(skel->maps.percpu);
> +	opts.link_info = &linfo;
> +	opts.link_info_len = sizeof(linfo);
> +	link = bpf_program__attach_iter(skel->progs.dump_percpu_data, &opts);
> +	if (!ASSERT_OK_PTR(link, "bpf_program__attach_iter"))
> +		goto out;
> +
> +	fd = bpf_iter_create(bpf_link__fd(link));
> +	if (!ASSERT_GE(fd, 0, "bpf_iter_create"))
> +		goto out;
> +
> +	while ((len = read(fd, buf, sizeof(buf))) > 0)
> +		do { } while (0);

This isn't a bug, but would a bare semicolon (as in bpf_iter.c's
read-drain loops) be clearer here than do { } while (0)?

[ ... ]

> diff --git a/tools/testing/selftests/bpf/progs/test_global_percpu_data.c b/tools/testing/selftests/bpf/progs/test_global_percpu_data.c
> index d086e9417f9fb..71ff8d1bf49eb 100644
> --- a/tools/testing/selftests/bpf/progs/test_global_percpu_data.c
> +++ b/tools/testing/selftests/bpf/progs/test_global_percpu_data.c
> @@ -61,4 +61,29 @@ int verifier_snprintf(void *ctx)
>  	return 0;
>  }
>
> +volatile const __u32 num_cpus = 0;
> +volatile const int offsetof_num;

This isn't a bug, but would a name like nums6_off (set directly from
offsetof(struct test_global_percpu_data__percpu, struct_data.nums[6]))
make it clearer which field the iterator is summing?

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/31716447858