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 <[email protected]> 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/[email protected]?part=15
