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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `smp_mb()` macro performs an atomic read-modify-write on an uninitialized local stack variable `__val`, which will be rejected by the BPF verifier on non-x86 architectures, breaking the tool completely.
--

commit 8906134488c74fb8663c6c7d837a2ee2c7d3ebb4
Author: Gabriele Monaco <gmonaco@redhat.com>

tools/rv: Copy stripped bpf_atomic.h from libarena

This commit adds bpf_atomic.h to tools/verification/rv/bpf_monitors,
providing atomic read/write macros like READ_ONCE() and try_cmpxchg(). It
is a stripped down copy of the version currently present in
selftests/bpf/libarena.

> 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 0000000000000..f834ea91c9d34
> --- /dev/null
> +++ b/tools/verification/rv/bpf_monitors/bpf_atomic.h
> @@ -0,0 +1,105 @@

[ ... ]

> +#define smp_mb()                                 \
> +	({                                       \
> +		volatile unsigned long __val;    \
> +		__sync_fetch_and_add(&__val, 0); \
> +	})

[Severity: Medium]
Will this macro cause the BPF verifier to reject the program on non-x86
architectures?

Because __val is an uninitialized local stack variable, the
__sync_fetch_and_add() instruction performs a read-modify-write on
uninitialized memory. The BPF verifier strictly enforces that memory read
by atomic instructions is initialized.

Since the variable evaluates as STACK_INVALID, the verifier will block the
monitor program with an invalid read from stack error. Should __val be
initialized to zero before the atomic fetch-and-add?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831090524.106845-1-gmonaco@redhat.com?part=15