Re: [PATCH bpf] selftests/bpf: Skip libarena when the BPF backend lacks 32-bit arena cmpxchg

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] The patch misdiagnoses the root cause of the Clang crash and implements a workaround that incorrectly skips `libarena` tests instead of fixing the underlying build configuration.

Pre-existing issues:
- [High] The patch fails to apply the new 32-bit cmpxchg guard to the ASAN variant of `libarena`, leaving the selftests build vulnerable to the exact same compiler crash it attempts to fix.
--

commit e34c5b107c762422f1dc3835420230ecdcd78708
Author: George Guo <guodongtai@kylinos.cn>

selftests/bpf: Skip libarena when the BPF backend lacks 32-bit arena cmpxchg

This patch introduces a feature probe to detect if the BPF backend supports
32-bit arena cmpxchg operations. It skips building libarena and its
dependent tests if the operation is unsupported to prevent build aborts.

> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index b642ee489ea64..0098d892cb39e 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile

[ ... ]

> @@ -91,6 +91,17 @@ CLANG_HAS_ARENA_ASAN := $(shell echo 'int x;' | \
>  	-mllvm -asan-shadow-addr-space=1 \
>  	-x c -c - -o /dev/null 2>/dev/null && echo 1)
>  
> +# The arena qspinlock used by libarena performs a 32-bit atomic cmpxchg on an
> +# arena (address space 1) pointer. Not every LLVM BPF backend can select it;
> +# older releases bail out with "unsupported atomic operation, please use 64 bit
> +# version", which aborts the whole selftests build. Probe for the operation and
> +# skip libarena (and its dependent tests) when the backend cannot handle it.
> +CLANG_HAS_ARENA_CMPXCHG32 := $(shell printf '%s\n' \
> +	'struct s { int counter; };' \
> +	'int f(struct s __attribute__((address_space(1))) *l, int o, int n)' \
> +	'{ return __sync_val_compare_and_swap(&l->counter, o, n); }' | \
> +	$(CLANG) --target=bpf -O2 -x c -c - -o /dev/null 2>/dev/null && echo 1)
> +

[Severity: High]
Does this feature probe artificially fail by omitting the -mcpu=v4 flag?

Because the probe runs against the default BPF CPU target (which lacks 32-bit
atomic support), it will falsely report that the backend lacks support and
unnecessarily skip the tests.

Could the actual root cause of the build failure be that libarena's
BPF_CFLAGS in tools/testing/selftests/bpf/libarena/Makefile is missing
the -mcpu=v4 flag? 

For example, test_progs-cpuv4 successfully compiles progs/arena_spin_lock.c
because it explicitly passes -mcpu=v4. Would adding -mcpu=v4 to the
libarena Makefile fix the compilation error natively instead of skipping
the tests entirely?

>  # Order correspond to 'make run_tests' order
>  TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_progs \
>  	test_sockmap \

[ ... ]

> @@ -835,10 +846,13 @@ LIBARENA_BPF_DEPS := $(wildcard libarena/Makefile		\
>  				 libarena/selftests/*		\
>  				 libarena/*.bpf.o)
>  
> +ifneq ($(CLANG_HAS_ARENA_CMPXCHG32),)
>  LIBARENA_SKEL := libarena/libarena.skel.h
> +CFLAGS += -DHAS_BPF_ARENA
>  
>  $(LIBARENA_SKEL): $(INCLUDE_DIR)/vmlinux.h $(BPFOBJ) $(LIBARENA_BPF_DEPS)
>  	+$(MAKE) -C libarena libarena.skel.h $(LIBARENA_MAKE_ARGS)
> +endif
>  
>  ifneq ($(CLANG_HAS_ARENA_ASAN),)
>  LIBARENA_ASAN_SKEL := libarena/libarena_asan.skel.h

[Severity: High]
This is a pre-existing issue, but doesn't the ASAN variant of libarena
also need protection from this compiler crash?

The LIBARENA_ASAN_SKEL build is only guarded by CLANG_HAS_ARENA_ASAN, which
checks for ASAN flag support but not 32-bit cmpxchg support. 

Since the ASAN build compiles the exact same buddy.bpf.c source code
containing the 32-bit arena cmpxchg, the compiler will still crash here
with the exact same "Cannot select: AtomicCmpSwap" error if the target
lacks 32-bit atomics.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630025809.74043-1-dongtai.guo@linux.dev?part=1