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 ';'.
>
> [ ... ]
>
>> 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
