Re: [PATCH bpf-next 07/16] libbpf: Add arena percpu feature probe

[bot+bpf-ci@kernel.org]

[-- Attachment #1: Type: text/plain, Size: 3570 bytes --]

> libbpf: Add arena percpu feature probe

TL;DR: The new arena percpu probe check in bpf_object__relocate() lacks an
arena_map->autocreate condition, so on kernels without the feature, objects
with .arena.percpu data may fail to load with -EOPNOTSUPP even when the arena
is disabled.

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 8634778e8ba5..be2ddaf96631 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> @@ -8288,6 +8288,12 @@ static int bpf_object__relocate(struct bpf_object *obj, const char *targ_btf_pat
>  			return -EOPNOTSUPP;
>  		}
>
> +		if (obj->arena_percpu.present && !kernel_supports(obj, FEAT_ARENA_PERCPU_DATA)) {
> +			pr_warn("map '%s': kernel doesn't support %s variables\n",
> +				arena_map->name, ARENA_PERCPU_SEC);
> +			return -EOPNOTSUPP;
> +		}
> +

Should this check also require arena_map->autocreate?

As written, any object with a .arena.percpu section fails to load on a
kernel without this feature, even when the arena map is not going to be
created.

The rest of the series supports an arena map with autocreate == false:

  bpf_object__relocate_data(), RELO_ARENA_PERCPU:
      if (map->autocreate) {
          insn[0].src_reg = BPF_PSEUDO_ARENA_PERCPU; ...
      } else {
          poison_map_ldimm64(...);
      }

  bpf_object__relocate_data_ptrs():
      if (!arena->autocreate)
          return 0;

  bpf_object__bind_arena():
      if (!map->autocreate || map->fd < 0 || ...)
          return 0;

The later commit 6714f66de847 ("libbpf: Introduce arena percpu helpers for
user space") also documents bpf_map__arena_percpu_base() as returning NULL
for a map with autocreate == false.

The related FEAT_PERCPU_DATA and FEAT_GLOBAL_DATA handling in
bpf_object__create_maps() skips creating the map and only fails the
programs that are loaded and reference it:

  If those global variable-using programs are not loaded at runtime due to
  bpf_program__set_autoload(prog, false), bpf_object loading will succeed
  just fine even on old kernels. Same skipping applies to percpu data.

Consider a kernel that supports arenas but not arena percpu, or an arch
whose JIT lacks bpf_jit_supports_arena_percpu_insn().  The application
calls bpf_map__set_autocreate(arena, false) and
bpf_program__set_autoload(prog_using_percpu, false), then
bpf_object__load():

bpf_object__load()
  bpf_object_load()
    bpf_object_prepare()
      bpf_object__relocate()
        return -EOPNOTSUPP;

At the parent commit 422f64147751 this same object loaded: the arena was
skipped in bpf_object__create_maps(), percpu ldimm64 instructions in
programs that are not autoloaded were never relocated, and poisoned ones
are only rejected if the program is loaded.

libbpf has no public probe for this feature, and retrying with the arena
disabled hits the same check.  Is there any configuration on such kernels
that can load an object carrying arena percpu data, including its programs
that do not use the arena?

Adding arena_map->autocreate && to the condition would keep the early, clear
error for the normal case while keeping the autocreate == false path
working.

The commit message says "fail objects carrying arena percpu data with
-EOPNOTSUPP when it is missing", but it does not say why this should apply
when the arena map is not going to be created.


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