From: bot+bpf-ci@kernel.org
To: xukuohai@huaweicloud.com,bpf@vger.kernel.org,linux-kernel@vger.kernel.org
Cc: ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,eddyz87@gmail.com,memxor@gmail.com,emil@etsalapatis.com,yonghong.song@linux.dev,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 02/16] libbpf: Create arena percpu chunk from the arena percpu ELF section
Date: Tue, 20 Oct 2026 14:17:17 +0000 (UTC) [thread overview]
Message-ID: <382819e642302a560c3a9caa157a604c0711828de9ecde51ef490d7cf2f34a3d@mail.kernel.org> (raw)
In-Reply-To: <09a19ff6dfc65af56dca0ec5cee051766470f36a.1792503001.git.xukuohai@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]
> libbpf: Create arena percpu chunk from the arena percpu ELF section
TL;DR: Reading the possible-CPUs sysfs file at open time may make
bpf_object_open() fail, breaking 'bpftool gen skeleton' in sandboxes without
/sys; suggests computing nr_chunks lazily in relocate.
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
[ ... ]
> @@ -3267,6 +3274,41 @@ static int bpf_object__init_arena_data(struct bpf_object *obj)
> return 0;
> }
>
> +static int init_arena_percpu_data(struct bpf_object *obj, void *percpu_data, size_t percpu_sz)
> +{
> + static const char *fcpu = "/sys/devices/system/cpu/possible";
> + bool *mask = NULL;
> + int possible_cpus;
> + int err;
> +
> + if (percpu_sz == 0) {
> + pr_warn("arena percpu: empty %s section\n", ARENA_PERCPU_SEC);
> + return -EINVAL;
> + }
> +
> + err = parse_cpu_mask_file(fcpu, &mask, &possible_cpus);
> + if (err) {
> + pr_warn("arena percpu: failed to get possible cpus: %s\n",
> + errstr(err));
> + return err;
> + }
Can this make bpf_object_open() fail on hosts where
/sys/devices/system/cpu/possible cannot be read?
init_arena_percpu_data() is reached from bpf_object__init_user_btf_maps()
during bpf_object_open(), so opening any object with a .arena.percpu section
now reads this sysfs file. Until now libbpf only needed the possible CPU
count at load or runtime, through map_set_def_max_entries(), the per-cpu
value size checks and perf_buffer setup.
The value computed here, obj->arena_percpu.nr_chunks, is first used in
bpf_object__relocate(), which runs from bpf_object_prepare():
> + size_t percpu_sz = obj->arena_percpu.nr_chunks * obj->arena_percpu.chunk_sz;
Open-only consumers such as 'bpftool gen skeleton' and 'bpftool gen
subskeleton' call bpf_object__open_mem() and never load, so they now depend
on the build host's sysfs. In a build chroot or sandbox without /sys, open
fails with "arena percpu: failed to get possible cpus" and skeleton
generation breaks, even though the CPU count is never used there.
With 'gen skeleton -L', open fails with this error before the intended
-EOPNOTSUPP check in bpf_object__relocate() is reached:
> + if (obj->gen_loader && obj->arena_percpu.present) {
> + pr_warn("map '%s': light skeletons don't support arena percpu variables\n",
> + arena_map->name);
> + return -EOPNOTSUPP;
> + }
Would it work to allocate and copy the chunk at open time, and compute
nr_chunks lazily in bpf_object__relocate(), where it is first needed? No
later commit in the series changes this.
> +
> + obj->arena_percpu.chunk_sz = roundup(percpu_sz, sysconf(_SC_PAGE_SIZE));
> + obj->arena_percpu.chunk = calloc(1, obj->arena_percpu.chunk_sz); /* zero padding */
> + if (!obj->arena_percpu.chunk) {
> + free(mask);
> + return -ENOMEM;
> + }
[ ... ]
---
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/39434884362
next prev parent reply other threads:[~2026-10-20 14:17 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 13:22 [PATCH bpf-next 00/16] Add percpu variable support for bpf arena Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 01/16] libbpf: Collect arena percpu data section Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 02/16] libbpf: Create arena percpu chunk from the arena percpu ELF section Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci [this message]
2026-10-20 13:22 ` [PATCH bpf-next 03/16] libbpf: Place the percpu chunks in the bpf arena Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 04/16] libbpf: Copy the percpu chunks into " Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 05/16] libbpf: Add the arena percpu chunk attribute to map creation options Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 06/16] libbpf: Relocate arena percpu access instructions Xu Kuohai
2026-10-20 14:29 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 07/16] libbpf: Add arena percpu feature probe Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 08/16] bpf: Extend syscall to accept arena percpu information Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 09/16] bpf: Teach verifier about arena percpu instructions Xu Kuohai
2026-10-20 14:29 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 10/16] bpf, x86: Add support for arena percpu Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 11/16] bpf, arm64: " Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 12/16] libbpf: Introduce arena percpu helpers for user space Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 13/16] bpftool: Emit the arena percpu datasec into skeleton Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 14/16] selftests/bpf: Add test for arena percpu-only object Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:23 ` [PATCH bpf-next 15/16] selftests/bpf: Add test for mixed arena percpu object Xu Kuohai
2026-10-20 13:23 ` [PATCH bpf-next 16/16] selftests/bpf: Add test for arena percpu bounds Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 14:47 ` [PATCH bpf-next 00/16] Add percpu variable support for bpf arena Alexei Starovoitov
2026-10-21 13:53 ` Xu Kuohai
2026-10-21 16:51 ` Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=382819e642302a560c3a9caa157a604c0711828de9ecde51ef490d7cf2f34a3d@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=mason@kernel.org \
--cc=memxor@gmail.com \
--cc=xukuohai@huaweicloud.com \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®