On Fri, 2024-02-23 at 10:29 +0800, Yafang Shao wrote: [...] > > The patch 1 looks good, but this test fails on s390. > > > > read_percpu_data:FAIL:nr_cpus unexpected nr_cpus: actual 0 != expected 2 > > verify_iter_success:FAIL:read_percpu_data unexpected error: -1 (errno 95) > > > > Please see CI. > > > > So either add it to DENYLIST.s390x in the same commit or make it work. > > > > pw-bot: cr > > The reason for the failure on s390x architecture is currently unclear. > One plausible explanation is that total_nr_cpus remains 0 when > executing the following code: > > bpf_for_each(bits, cpu, p->cpus_ptr, total_nr_cpus) > > This is despite setting total_nr_cpus to the value obtained from > libbpf_num_possible_cpus(): > > skel->bss->total_nr_cpus = libbpf_num_possible_cpus(); > > A potential workaround could involve using a hardcoded number of CPUs, > such as 8192, instead of relying on total_nr_cpus. This approach might > mitigate the issue temporarily. I'm sorry, but is it really necessary to deal with total number of CPUs in a test for bit iterator? Tbh, cpumask_iter / verify_iter_success seem to be over-complicated. Would it be possible to reuse test_loader.c's RUN_TESTS for this feature? It supports __retval(...) annotation, so it should be possible to: - create a map (even a constant map) with some known data; - peek a BPF program type that supports BPF_PROG_TEST_RUN syscall command; - organize test BPF programs so that they create bit iterators for this test data and return some expected quantities (e.g. a sum), verified by __retval. This should limit the amount of code on prog_tests/*.c side to the bare minimum.
