> 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 7d6bda909295..2f0dbeb88934 100644
> --- a/tools/testing/selftests/bpf/prog_tests/global_data_init.c
> +++ b/tools/testing/selftests/bpf/prog_tests/global_data_init.c
[ ... ]
> @@ -126,11 +123,11 @@ static void test_percpu_data_on_cpus(struct bpf_map *map, int map_fd, int prog_f
> static void test_global_percpu_data_init(void)
> {
> struct test_global_percpu_data__percpu init_value = {};
> + const __u32 desired_sz = sysconf(_SC_PAGE_SIZE) * 2;
> struct test_global_percpu_data__percpu *init_data;
> - const __u32 desired_sz = sysconf(_SC_PAGE_SIZE);
Does multiplying by 2 here break the test on 64K page systems?
Per-CPU array value sizes are capped by the kernel:
/* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */
if (percpu && round_up(attr->value_size, 8) > PCPU_MIN_UNIT_SIZE)
return -E2BIG;
in kernel/bpf/arraymap.c:array_map_alloc_check(), where PCPU_MIN_UNIT_SIZE
is defined as:
#define PCPU_MIN_UNIT_SIZE PFN_ALIGN(32 << 10)
which equals max(32768, PAGE_SIZE).
The old code was safe by construction: desired_sz == PAGE_SIZE <=
PFN_ALIGN(32768) == PCPU_MIN_UNIT_SIZE. Doubling it breaks that:
PAGE_SIZE 4096 -> limit 32768, request 8192 OK
PAGE_SIZE 16384 -> limit 32768, request 32768 OK (exactly at limit)
PAGE_SIZE 65536 -> limit 65536, request 131072 -E2BIG
On kernels built with 64K pages (arm64 CONFIG_ARM64_64K_PAGES, ppc64)
bpf_map__set_value_size() still succeeds (it is purely userspace
bookkeeping), all four assertions that follow it pass, and then map
creation fails inside test_global_percpu_data__load():
> err = test_global_percpu_data__load(skel);
> if (!ASSERT_OK(err, "test_global_percpu_data__load"))
> goto out;
The "global_percpu_data/init" subtest fails, and test_percpu_data_on_cpus()
is never reached. That is a new failure introduced by this patch (with
desired_sz == PAGE_SIZE the same configuration created a 65536-byte per-CPU
value, which is exactly at the limit and accepted).
Note that the neighbouring resize test in global_map_resize.c deliberately
does not scale a per-CPU map by page size for this reason. At line 46 it
uses:
new_sz = sizeof(skel->data_percpu_arr->percpu_arr[0]) *
libbpf_num_possible_cpus();
A size that is independent of PAGE_SIZE would still force the mmap region
to move, which is what the new skel->percpu_arr reassignment and the
arr[0] == -1 check are there to exercise, without hitting the per-CPU
allocator bound.
> struct test_global_percpu_data *skel = NULL;
> + struct bpf_map *map, *map_percpu_arr;
> size_t init_data_sz;
> - struct bpf_map *map;
> int prog_fd, err;
[ ... ]
> @@ -177,33 +176,37 @@ static void test_global_percpu_data_init(void)
>
> ASSERT_EQ(init_data->data, init_value.data, "init_value data");
> ASSERT_EQ(init_data->set, init_value.set, "init_value set");
> + ASSERT_EQ(init_data->nums[6], init_value.nums[6], "init_value nums[6]");
[ ... ]
> - ASSERT_GT(desired_sz, sizeof(init_value), "desired_sz");
> - err = bpf_map__set_value_size(map, desired_sz);
> + skel->percpu_arr->arr[0] = -1;
> + map_percpu_arr = skel->maps.percpu_arr;
> + err = bpf_map__set_value_size(map_percpu_arr, desired_sz);
> if (!ASSERT_OK(err, "bpf_map__set_value_size"))
> goto out;
[ ... ]
> 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 71ff8d1bf49e..12556590b647 100644
> --- a/tools/testing/selftests/bpf/progs/test_global_percpu_data.c
> +++ b/tools/testing/selftests/bpf/progs/test_global_percpu_data.c
> @@ -8,9 +8,11 @@ int loong SEC(".percpu.looooooooong");
> int data3 SEC(".data.percpu");
> int data2 SEC(".percpu.data");
>
> +/* Used for testing bpf_map__set_value_size(). */
> +int arr[1] SEC(".percpu.arr");
> +
> int run;
> -/* cpu_id as array to verify map value resizing. */
> -int cpu_id[1] SEC(".percpu");
> +int cpu_id SEC(".percpu");
> int data SEC(".percpu") = -1;
> int nums[7] SEC(".percpu");
> bool set SEC(".percpu") = false;
[ ... ]
---
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/31826359148
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.