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

Andrii Nakryiko <[email protected]>
Newsgroups org.kernel.vger.linux-kselftest,org.kernel.vger.bpf,org.kernel.vger.linux-kernel
Message-ID <CAEf4BzZWV7EQJpmS2dddkgVeDqXLun8UuGbNNzrQ6SVMEMTRtw@mail.gmail.com>
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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.