> 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
