On Thu, Aug 13, 2026 at 11:13 PM Leon Hwang <[email protected]> wrote:
>
> On 14/8/26 00:26, [email protected] wrote:
> >> 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?
>
> Sure. Will update.
>
> >
> >> + 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)?
>
> Prefer 'do { } while (0);' instead of a dangling ';'.
humans used to have {} or { /* no-op */ } for cases like this, not a
dangling semicolon
do {} while (0) is for macros only
>
> >
> > [ ... ]
> >
> >> 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?
>
> 'num_off' would be better.
>
> In iter, it should not know the concrete number. Instead, it identifies
> the number by offset 'num_off'.
>
> Thanks,
> Leon
>
> >
> > [ ... ]
> >
> >
> > ---
> > 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
>
