> 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
