Re: [PATCH v2 09/15] tools/rv: Copy stripped bpf_atomic.h from libarena

[bot+bpf-ci]

> tools/rv: Copy stripped bpf_atomic.h from libarena

TL;DR: The CONFIG_X86_64 kconfig extern in bpf_atomic.h may make BPF monitors
fail to load (-EINVAL) on hosts without a readable kernel config, but only in
the bisect window until a later patch fixes it.

> diff --git a/tools/verification/rv/bpf_monitors/bpf_atomic.h b/tools/verification/rv/bpf_monitors/bpf_atomic.h
> new file mode 100644
> index 000000000000..f834ea91c9d3
> --- /dev/null
> +++ b/tools/verification/rv/bpf_monitors/bpf_atomic.h
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2025 Meta Platforms, Inc. and affiliates. */
> +#ifndef BPF_ATOMIC_H
> +#define BPF_ATOMIC_H
> +
> +#include <vmlinux.h>
> +#include <bpf/bpf_helpers.h>
> +
> +extern bool CONFIG_X86_64 __kconfig __weak;

Can this extern make every BPF monitor fail to load on a host that has no
readable kernel config?

smp_load_acquire() and smp_store_release() reference CONFIG_X86_64, and
include/rv/da_monitor.h uses these macros (da_monitoring(),
da_monitor_start(), da_monitor_reset_state()), so each monitor object ends
up with a CONFIG_ kconfig extern.

The __weak attribute does not make it optional in that case.  In libbpf,
bpf_object__resolve_externs() sets need_config for any extern whose name
starts with "CONFIG_", and then requires the config file to be readable:

    if (str_has_pfx(ext->name, "CONFIG_")) {
        need_config = true;
        continue;
    }
    ...
    if (need_config) {
        err = bpf_object__read_kconfig_file(obj, kcfg_data);
        if (err)
            return -EINVAL;
    }

bpf_object__read_kconfig_file() returns -ENOENT when neither
/boot/config-$(uname -r) nor /proc/config.gz exists.

Once f5fc86049b84 ("tools/rv: Add BPF monitors") includes this header via
da_monitor_bpf.h, open_bpf_monitor() calls bpf_object__open_file(path, NULL)
followed by bpf_object__load(obj).  That load would fail with -EINVAL on
self-built kernels without CONFIG_IKCONFIG_PROC, or in containers without
/boot/config-*.

The series fixes this later in 3b66b9d4a13a ("tools/rv: Define CONFIG_X86_64
statically for BPF monitors"), which passes .kconfig = "CONFIG_X86_64=y|n"
through bpf_object_open_opts.  So the failure is limited to the bisect
window f5fc86049b84..3b66b9d4a13a^.

Could that fix be folded in before f5fc86049b84, or could this header
resolve the architecture at compile time, so that every step of the series
stays loadable?


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