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

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