Re: [PATCH bpf-next 01/16] libbpf: Collect arena percpu data section

[bot+bpf-ci]

> libbpf: Collect arena percpu data section

TL;DR: Objects with .arena.percpu but no .maps section may get a misleading
libbpf error naming .addr_space.1 and "global __arena variables"; it's a
message-wording question, not a functional problem.

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 8fcb8cf39cc0..d79fc382319e 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> @@ -3201,7 +3212,7 @@ static int bpf_object__init_arena_data(struct bpf_object *obj)
>
>  	if (obj->arena_map_idx < 0) {
>  		/* bpf_object__init_user_btf_maps() didn't look: there is no .maps section */
> -		if (obj->efile.arena_data) {
> +		if (obj->efile.arena_data || obj->efile.arena_percpu_data) {
>  			pr_warn("elf: sec '%s': to use global __arena variables the ARENA map should be explicitly declared in SEC(\".maps\")\n",
>  				ARENA_SEC);
>  			return -ENOENT;

The condition now also fires on obj->efile.arena_percpu_data, but the warning
still names ARENA_SEC and talks about "global __arena variables".  Is that the
intended message for the percpu case?

Consider an object with no SEC(".maps"), the ".arena.data" marker (the
data_in_arena case), some .data/.bss, a ".arena.percpu" section and no
".addr_space.1" section.  bpf_object__init_user_btf_maps() returns 0 early
because btf_maps_shndx < 0, so its new ARENA_PERCPU_SEC message never runs.

bpf_object__init_arena_data() then reaches this block with arena_data == NULL
and arena_percpu_data != NULL, and prints:

  elf: sec '.addr_space.1': to use global __arena variables the ARENA map
  should be explicitly declared in SEC(".maps")

That points at a section the object does not have and at a kind of variable
the user did not declare.  The real problem is the .arena.percpu variables.

The same patch adds a separate message for this case in
bpf_object__init_user_btf_maps():

  pr_warn("elf: sec '%s': to use arena percpu variables the ARENA map should be explicitly declared in SEC(\".maps\")\n",
          ARENA_PERCPU_SEC);

So the two paths report the same condition differently.  Should the no-.maps
path in bpf_object__init_arena_data() choose its section name and wording
based on which of arena_data / arena_percpu_data is set?

The message is unchanged at the end of the series (08224ba2de19
"selftests/bpf: Add test for arena percpu bounds"), so no later commit
addresses this.


---
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