[PATCH bpf-next v1] selftests/bpf: Guard addr_space_cast code with __BPF_FEATURE_ADDR_SPACE_CAST
When compiling the BPF selftests with Clang versions that do not support the addr_space_cast builtin, the build fails with assembly errors in "verifier_ldsx.c" [1].
The root cause is that the inline assembly using addr_space_cast is being processed by a compiler that lacks this feature. To resolve this, wrap the affected code sections (specifically the arena_ldsx_* test functions) with #if defined(__BPF_FEATURE_ADDR_SPACE_CAST). This ensures the code is only compiled when the Clang supports the necessary feature, preventing build failures on older or incompatible compiler versions.
This change maintains test coverage for systems with support while allowing the tests to build successfully in all environments.
[1]: root:tools/testing/selftests/bpf$ make
CLNG-BPF [test_progs] verifier_ldsx.bpf.o progs/verifier_ldsx.c:322:2: error: invalid operand for instruction 322 | "r1 = %[arena] ll;" | ^ <inline asm>:1:52: note: instantiated into assembly here 1 | r1 = arena ll;r0 = 0xdeadbeef;r0 = addr_space_cast(r0,... | ^
Fixes: f61654912404 ("selftests: bpf: Add tests for signed loads from arena") Signed-off-by: Jiayuan Chen jiayuan.chen@linux.dev --- tools/testing/selftests/bpf/progs/verifier_ldsx.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/bpf/progs/verifier_ldsx.c b/tools/testing/selftests/bpf/progs/verifier_ldsx.c index c8494b682c31..cefa02e417d3 100644 --- a/tools/testing/selftests/bpf/progs/verifier_ldsx.c +++ b/tools/testing/selftests/bpf/progs/verifier_ldsx.c @@ -263,6 +263,7 @@ __naked void ldsx_ctx_8(void) : __clobber_all); }
+#if defined(__BPF_FEATURE_ADDR_SPACE_CAST) SEC("syscall") __description("Arena LDSX Disasm") __success @@ -425,6 +426,7 @@ __naked void arena_ldsx_s32(void *ctx) : __clobber_all ); } +#endif
/* to retain debug info for BTF generation */ void kfunc_root(void)
On 10/22/25 12:18 AM, Jiayuan Chen wrote:
When compiling the BPF selftests with Clang versions that do not support the addr_space_cast builtin, the build fails with assembly errors in "verifier_ldsx.c" [1].
The root cause is that the inline assembly using addr_space_cast is being processed by a compiler that lacks this feature. To resolve this, wrap the affected code sections (specifically the arena_ldsx_* test functions) with #if defined(__BPF_FEATURE_ADDR_SPACE_CAST). This ensures the code is only compiled when the Clang supports the necessary feature, preventing build failures on older or incompatible compiler versions.
This change maintains test coverage for systems with support while allowing the tests to build successfully in all environments.
[1]: root:tools/testing/selftests/bpf$ make
CLNG-BPF [test_progs] verifier_ldsx.bpf.o progs/verifier_ldsx.c:322:2: error: invalid operand for instruction 322 | "r1 = %[arena] ll;" | ^ <inline asm>:1:52: note: instantiated into assembly here 1 | r1 = arena ll;r0 = 0xdeadbeef;r0 = addr_space_cast(r0,... | ^
I think you are using llvm18 and earlier. Why can you upgrade to llvm19 and later which should solve the problem?
Fixes: f61654912404 ("selftests: bpf: Add tests for signed loads from arena")
We do not need to have Fixes. compiler is also moving forward, we cannot support really old compiler and it is no point to have __BPF_FEATURE_ADDR_SPACE_CAST for really old compilers. So at some point, __BPF_FEATURE_ADDR_SPACE_CAST will become default.
Signed-off-by: Jiayuan Chen jiayuan.chen@linux.dev
tools/testing/selftests/bpf/progs/verifier_ldsx.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/bpf/progs/verifier_ldsx.c b/tools/testing/selftests/bpf/progs/verifier_ldsx.c index c8494b682c31..cefa02e417d3 100644 --- a/tools/testing/selftests/bpf/progs/verifier_ldsx.c +++ b/tools/testing/selftests/bpf/progs/verifier_ldsx.c @@ -263,6 +263,7 @@ __naked void ldsx_ctx_8(void) : __clobber_all); } +#if defined(__BPF_FEATURE_ADDR_SPACE_CAST) SEC("syscall") __description("Arena LDSX Disasm") __success @@ -425,6 +426,7 @@ __naked void arena_ldsx_s32(void *ctx) : __clobber_all ); } +#endif
If you are really using llvm18, then I found there are some other build failures as well, e.g.,
/home/yhs/work/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:47:15: error: conflicting types for 'bpf_arena_alloc_pages' 47 | void __arena* bpf_arena_alloc_pages(void *map, void __arena *addr, __u32 page_cnt, | ^ /home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:160636:48: note: previous declaration is here 160636 | extern void __attribute__((address_space(1))) *bpf_arena_alloc_pages(void *p__map, void __attribute__((address_space(1))) *addr__ign, u32 page_cnt, int node_id, u64 flags) __weak __ksym; | ^ In file included from progs/stream.c:8: /home/yhs/work/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:49:5: error: conflicting types for 'bpf_arena_reserve_pages' 49 | int bpf_arena_reserve_pages(void *map, void __arena *addr, __u32 page_cnt) __ksym __weak; | ^ /home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:160638:12: note: previous declaration is here 160638 | extern int bpf_arena_reserve_pages(void *p__map, void __attribute__((address_space(1))) *ptr__ign, u32 page_cnt) __weak __ksym; | ^ In file included from progs/stream.c:8: /home/yhs/work/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:50:6: error: conflicting types for 'bpf_arena_free_pages' 50 | void bpf_arena_free_pages(void *map, void __arena *ptr, __u32 page_cnt) __ksym __weak; | ^ /home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:160637:13: note: previous declaration is here 160637 | extern void bpf_arena_free_pages(void *p__map, void __attribute__((address_space(1))) *ptr__ign, u32 page_cnt) __weak __ksym; | ^
Please cover all build failures at once.
/* to retain debug info for BTF generation */ void kfunc_root(void)
On Wed, Oct 22, 2025 at 8:33 AM Yonghong Song yonghong.song@linux.dev wrote:
On 10/22/25 12:18 AM, Jiayuan Chen wrote:
When compiling the BPF selftests with Clang versions that do not support the addr_space_cast builtin, the build fails with assembly errors in "verifier_ldsx.c" [1].
The root cause is that the inline assembly using addr_space_cast is being processed by a compiler that lacks this feature. To resolve this, wrap the affected code sections (specifically the arena_ldsx_* test functions) with #if defined(__BPF_FEATURE_ADDR_SPACE_CAST). This ensures the code is only compiled when the Clang supports the necessary feature, preventing build failures on older or incompatible compiler versions.
This change maintains test coverage for systems with support while allowing the tests to build successfully in all environments.
[1]: root:tools/testing/selftests/bpf$ make
CLNG-BPF [test_progs] verifier_ldsx.bpf.o progs/verifier_ldsx.c:322:2: error: invalid operand for instruction 322 | "r1 = %[arena] ll;" | ^ <inline asm>:1:52: note: instantiated into assembly here 1 | r1 = arena ll;r0 = 0xdeadbeef;r0 = addr_space_cast(r0,... | ^
I think you are using llvm18 and earlier. Why can you upgrade to llvm19 and later which should solve the problem?
Fixes: f61654912404 ("selftests: bpf: Add tests for signed loads from arena")
We do not need to have Fixes. compiler is also moving forward, we cannot support really old compiler and it is no point to have __BPF_FEATURE_ADDR_SPACE_CAST for really old compilers. So at some point, __BPF_FEATURE_ADDR_SPACE_CAST will become default.
+1 and this is not the first time we're seeing this type of patches. Upgrade your compiler. That's the only way.
pw-bot: cr
October 22, 2025 at 23:33, "Yonghong Song" <yonghong.song@linux.dev mailto:yonghong.song@linux.dev?to=%22Yonghong%20Song%22%20%3Cyonghong.song%40linux.dev%3E > wrote:
On 10/22/25 12:18 AM, Jiayuan Chen wrote:
When compiling the BPF selftests with Clang versions that do not support
If you are really using llvm18, then I found there are some other build failures as well, e.g.,
Yes i'm using llvm18
/home/yhs/work/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:47:15: error: conflicting types for 'bpf_arena_alloc_pages' 47 | void __arena* bpf_arena_alloc_pages(void *map, void __arena *addr, __u32 page_cnt, | ^ /home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:160636:48: note: previous declaration is here 160636 | extern void __attribute__((address_space(1))) *bpf_arena_alloc_pages(void *p__map, void __attribute__((address_space(1))) *addr__ign, u32 page_cnt, int node_id, u64 flags) __weak __ksym; | ^
I hadn't encountered this error before, but it started appearing after I upgraded LLVM to version 20.
$ make V=1
/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool btf dump file /home/chenjiayuan/code/upstream/bpf-next/vmlinux format c > /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/.vmlinux.h.tmp cmp -s /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/.vmlinux.h.tmp /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h || mv /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/.vmlinux.h.tmp /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h clang -g -Wall -Werror -D__TARGET_ARCH_x86 -mlittle-endian -I/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include -I/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf -I/home/chenjiayuan/code/upstream/bpf-next/tools/include/uapi -I/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/usr/include -std=gnu11 -fno-strict-aliasing -Wno-compare-distinct-pointer-types -idirafter /usr/lib/llvm-20/lib/clang/20/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -DENABLE_ATOMICS_TESTS -O2 --target=bpfel -c progs/stream.c -mcpu=v3 -o /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/stream.bpf.o In file included from progs/stream.c:8: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:47:15: error: conflicting types for 'bpf_arena_alloc_pages' 47 | void __arena* bpf_arena_alloc_pages(void *map, void __arena *addr, __u32 page_cnt, | ^ /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:152158:14: note: previous declaration is here 152158 | extern void *bpf_arena_alloc_pages(void *p__map, void *addr__ign, u32 page_cnt, int node_id, u64 flags) __weak __ksym; | ^ In file included from progs/stream.c:8: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:49:5: error: conflicting types for 'bpf_arena_reserve_pages' 49 | int bpf_arena_reserve_pages(void *map, void __arena *addr, __u32 page_cnt) __ksym __weak; | ^ /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:152160:12: note: previous declaration is here 152160 | extern int bpf_arena_reserve_pages(void *p__map, void *ptr__ign, u32 page_cnt) __weak __ksym; | ^ In file included from progs/stream.c:8: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:50:6: error: conflicting types for 'bpf_arena_free_pages' 50 | void bpf_arena_free_pages(void *map, void __arena *ptr, __u32 page_cnt) __ksym __weak; | ^ /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:152159:13: note: previous declaration is here 152159 | extern void bpf_arena_free_pages(void *p__map, void *ptr__ign, u32 page_cnt) __weak __ksym; | ^ 3 errors generated. make: *** [Makefile:761: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/stream.bpf.o] Error 1
$ clang --version Ubuntu clang version 20.1.8 (++20250804090239+87f0227cb601-1~exp1~20250804210352.139) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm-20/bin
$ pahole --version v1.29
I updated LLVM via https://apt.llvm.org/. Could this be caused by some binaries or libraries still using LLVM 18?
On 10/22/25 8:33 PM, Jiayuan Chen wrote:
October 22, 2025 at 23:33, "Yonghong Song" <yonghong.song@linux.dev mailto:yonghong.song@linux.dev?to=%22Yonghong%20Song%22%20%3Cyonghong.song%40linux.dev%3E > wrote:
On 10/22/25 12:18 AM, Jiayuan Chen wrote:
When compiling the BPF selftests with Clang versions that do not support
If you are really using llvm18, then I found there are some other build failures as well, e.g.,
Yes i'm using llvm18
/home/yhs/work/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:47:15: error: conflicting types for 'bpf_arena_alloc_pages' 47 | void __arena* bpf_arena_alloc_pages(void *map, void __arena *addr, __u32 page_cnt, | ^ /home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:160636:48: note: previous declaration is here 160636 | extern void __attribute__((address_space(1))) *bpf_arena_alloc_pages(void *p__map, void __attribute__((address_space(1))) *addr__ign, u32 page_cnt, int node_id, u64 flags) __weak __ksym; | ^
I hadn't encountered this error before, but it started appearing after I upgraded LLVM to version 20.
$ make V=1
/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool btf dump file /home/chenjiayuan/code/upstream/bpf-next/vmlinux format c > /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/.vmlinux.h.tmp cmp -s /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/.vmlinux.h.tmp /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h || mv /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/.vmlinux.h.tmp /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h clang -g -Wall -Werror -D__TARGET_ARCH_x86 -mlittle-endian -I/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include -I/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf -I/home/chenjiayuan/code/upstream/bpf-next/tools/include/uapi -I/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/usr/include -std=gnu11 -fno-strict-aliasing -Wno-compare-distinct-pointer-types -idirafter /usr/lib/llvm-20/lib/clang/20/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -DENABLE_ATOMICS_TESTS -O2 --target=bpfel -c progs/stream.c -mcpu=v3 -o /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/stream.bpf.o In file included from progs/stream.c:8: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:47:15: error: conflicting types for 'bpf_arena_alloc_pages' 47 | void __arena* bpf_arena_alloc_pages(void *map, void __arena *addr, __u32 page_cnt, | ^ /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:152158:14: note: previous declaration is here 152158 | extern void *bpf_arena_alloc_pages(void *p__map, void *addr__ign, u32 page_cnt, int node_id, u64 flags) __weak __ksym; | ^ In file included from progs/stream.c:8: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:49:5: error: conflicting types for 'bpf_arena_reserve_pages' 49 | int bpf_arena_reserve_pages(void *map, void __arena *addr, __u32 page_cnt) __ksym __weak; | ^ /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:152160:12: note: previous declaration is here 152160 | extern int bpf_arena_reserve_pages(void *p__map, void *ptr__ign, u32 page_cnt) __weak __ksym; | ^ In file included from progs/stream.c:8: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:50:6: error: conflicting types for 'bpf_arena_free_pages' 50 | void bpf_arena_free_pages(void *map, void __arena *ptr, __u32 page_cnt) __ksym __weak; | ^ /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:152159:13: note: previous declaration is here 152159 | extern void bpf_arena_free_pages(void *p__map, void *ptr__ign, u32 page_cnt) __weak __ksym; | ^ 3 errors generated. make: *** [Makefile:761: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/stream.bpf.o] Error 1
$ clang --version Ubuntu clang version 20.1.8 (++20250804090239+87f0227cb601-1~exp1~20250804210352.139) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm-20/bin
$ pahole --version v1.29
Please try pahole version 1.30.
I updated LLVM via https://apt.llvm.org/. Could this be caused by some binaries or libraries still using LLVM 18?
October 23, 2025 at 11:42, "Yonghong Song" <yonghong.song@linux.dev mailto:yonghong.song@linux.dev?to=%22Yonghong%20Song%22%20%3Cyonghong.song%40linux.dev%3E > wrote:
On 10/22/25 8:33 PM, Jiayuan Chen wrote:
October 22, 2025 at 23:33, "Yonghong Song" <yonghong.song@linux.dev mailto:yonghong.song@linux.dev?to=%22Yonghong%20Song%22%20%3Cyonghong.song%40linux.dev%3E > wrote:
On 10/22/25 12:18 AM, Jiayuan Chen wrote:
When compiling the BPF selftests with Clang versions that do not support
If you are really using llvm18, then I found there are some other build failures as well, e.g.,
Yes i'm using llvm18
/home/yhs/work/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:47:15: error: conflicting types for 'bpf_arena_alloc_pages' 47 | void __arena* bpf_arena_alloc_pages(void *map, void __arena *addr, __u32 page_cnt, | ^ /home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:160636:48: note: previous declaration is here 160636 | extern void __attribute__((address_space(1))) *bpf_arena_alloc_pages(void *p__map, void __attribute__((address_space(1))) *addr__ign, u32 page_cnt, int node_id, u64 flags) __weak __ksym; | ^
I hadn't encountered this error before, but it started appearing after I upgraded LLVM to version 20.
$ make V=1
/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool btf dump file /home/chenjiayuan/code/upstream/bpf-next/vmlinux format c > /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/.vmlinux.h.tmp cmp -s /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/.vmlinux.h.tmp /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h || mv /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/.vmlinux.h.tmp /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h clang -g -Wall -Werror -D__TARGET_ARCH_x86 -mlittle-endian -I/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include -I/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf -I/home/chenjiayuan/code/upstream/bpf-next/tools/include/uapi -I/home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/usr/include -std=gnu11 -fno-strict-aliasing -Wno-compare-distinct-pointer-types -idirafter /usr/lib/llvm-20/lib/clang/20/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -DENABLE_ATOMICS_TESTS -O2 --target=bpfel -c progs/stream.c -mcpu=v3 -o /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/stream.bpf.o In file included from progs/stream.c:8: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:47:15: error: conflicting types for 'bpf_arena_alloc_pages' 47 | void __arena* bpf_arena_alloc_pages(void *map, void __arena *addr, __u32 page_cnt, | ^ /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:152158:14: note: previous declaration is here 152158 | extern void *bpf_arena_alloc_pages(void *p__map, void *addr__ign, u32 page_cnt, int node_id, u64 flags) __weak __ksym; | ^ In file included from progs/stream.c:8: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:49:5: error: conflicting types for 'bpf_arena_reserve_pages' 49 | int bpf_arena_reserve_pages(void *map, void __arena *addr, __u32 page_cnt) __ksym __weak; | ^ /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:152160:12: note: previous declaration is here 152160 | extern int bpf_arena_reserve_pages(void *p__map, void *ptr__ign, u32 page_cnt) __weak __ksym; | ^ In file included from progs/stream.c:8: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/bpf_arena_common.h:50:6: error: conflicting types for 'bpf_arena_free_pages' 50 | void bpf_arena_free_pages(void *map, void __arena *ptr, __u32 page_cnt) __ksym __weak; | ^ /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:152159:13: note: previous declaration is here 152159 | extern void bpf_arena_free_pages(void *p__map, void *ptr__ign, u32 page_cnt) __weak __ksym; | ^ 3 errors generated. make: *** [Makefile:761: /home/chenjiayuan/code/upstream/bpf-next/tools/testing/selftests/bpf/stream.bpf.o] Error 1
$ clang --version Ubuntu clang version 20.1.8 (++20250804090239+87f0227cb601-1~exp1~20250804210352.139) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm-20/bin
$ pahole --version v1.29
Please try pahole version 1.30.
I updated LLVM via https://apt.llvm.org/. Could this be caused by some binaries or libraries still using LLVM 18?
thanks, but version 1.30 didn't work in my tests - even pahole's master branch fails, only the next branch works...
It seems that the 'old' pahole parses some kfuncs incorrectly, for example bpf_dynptr_slice().
./tools/sbin/bpftool btf dump file ../../../../vmlinux | grep bpf_dynptr_slice -A 2 'KF_bpf_dynptr_slice' val=23 'KF_bpf_dynptr_slice_rdwr' val=24 'KF_bpf_dynptr_clone' val=25 'KF_bpf_percpu_obj_new_impl' val=26 -- [68242] FUNC 'bpf_dynptr_slice' type_id=68241 linkage=static <- missing corresponding DECL_TAG ? [68243] FUNC 'bpf_dynptr_slice_rdwr' type_id=68241 linkage=static [68244] DECL_TAG 'bpf_kfunc' type_id=68243 component_idx=-1 [68245] FUNC_PROTO '(anon)' ret_type_id=38 vlen=5
On Thu, Oct 23, 2025 at 12:50 AM Jiayuan Chen jiayuan.chen@linux.dev wrote:
thanks, but version 1.30 didn't work in my tests - even pahole's master branch fails, only the next branch works...
It seems that the 'old' pahole parses some kfuncs incorrectly, for example bpf_dynptr_slice().
Alan,
the introduction of the 'next' branch screwed up the workflow for many people. Let's remove it and merge everything into master. People expect master branch to be the one where active development is happening and the source of truth for the latest features.
On Thu, Oct 23, 2025 at 08:42:34AM -0700, Alexei Starovoitov wrote:
On Thu, Oct 23, 2025 at 12:50 AM Jiayuan Chen jiayuan.chen@linux.dev wrote:
thanks, but version 1.30 didn't work in my tests - even pahole's master branch fails, only the next branch works...
It seems that the 'old' pahole parses some kfuncs incorrectly, for example bpf_dynptr_slice().
l
Alan,
the introduction of the 'next' branch screwed up the workflow for many people. Let's remove it and merge everything into master. People expect master branch to be the one where active development is happening and the source of truth for the latest features.
My bad, I've been away for too long, next is supposed to be with things for a short while, testing for a few days, for CI consumption, then move to master, rinse repeat.
I think we should go back to that model.
- Arnaldo
On Mon, Oct 27, 2025 at 11:58:43AM -0300, Arnaldo Carvalho de Melo wrote:
On Thu, Oct 23, 2025 at 08:42:34AM -0700, Alexei Starovoitov wrote:
On Thu, Oct 23, 2025 at 12:50 AM Jiayuan Chen jiayuan.chen@linux.dev wrote:
thanks, but version 1.30 didn't work in my tests - even pahole's master branch fails, only the next branch works...
It seems that the 'old' pahole parses some kfuncs incorrectly, for example bpf_dynptr_slice().
l
Alan,
the introduction of the 'next' branch screwed up the workflow for many people. Let's remove it and merge everything into master. People expect master branch to be the one where active development is happening and the source of truth for the latest features.
My bad, I've been away for too long, next is supposed to be with things for a short while, testing for a few days, for CI consumption, then move to master, rinse repeat.
I think we should go back to that model.
The difference is small but can explain as has changes to the btf loader, and the reporter, as I now checked the whole thread, says that 'next' works for him, so I'll move what is in 'next' to 'master' now.
Just for reference since I had done it, my investigation is below.
- Arnaldo
⬢ [acme@toolbx pahole]$ git remote update korg Fetching korg ⬢ [acme@toolbx pahole]$ ⬢ [acme@toolbx pahole]$ git remote -v | grep korg korg https://git.kernel.org/pub/scm/devel/pahole/pahole.git (fetch) korg https://git.kernel.org/pub/scm/devel/pahole/pahole.git (push) ⬢ [acme@toolbx pahole]$ git diff --stat korg/master korg/next warning: refname 'korg/next' is ambiguous. .github/scripts/build-pahole.sh | 23 +++++++++++++++++++++++ .github/scripts/compare-functions.sh | 30 ++++++++++++++++++++++++++++++ .github/workflows/test.yml | 4 ++-- .github/workflows/vmtest.yml | 4 ++++ CMakeLists.txt | 5 ----- README | 4 ++++ btf_loader.c | 23 ++++++++++++++++++++--- dwarves_fprintf.c | 2 +- 8 files changed, 84 insertions(+), 11 deletions(-) ⬢ [acme@toolbx pahole]$
Related to btf bitfields:
diff --git a/btf_loader.c b/btf_loader.c index f4f9f65289b5acac..64ea68022ab04e60 100644 --- a/btf_loader.c +++ b/btf_loader.c @@ -645,9 +645,15 @@ static int class__fixup_btf_bitfields(const struct conf_load *conf, struct tag * pos->byte_size = tag__size(type, cu); pos->bit_size = pos->byte_size * 8;
- /* if BTF data is incorrect and has size == 0, skip field, - * instead of crashing */ + /* If the BTF data is incorrect and has size == 0, skip field + * instead of crashing. However the field can be a zero or + * variable-length array and we still need to infer alignment. + */ if (pos->byte_size == 0) { + pos->alignment = class__infer_alignment(conf, + pos->byte_offset, + tag__natural_alignment(type, cu), + smallest_offset); continue; }
@@ -672,7 +678,18 @@ static int class__fixup_btf_bitfields(const struct conf_load *conf, struct tag * pos->byte_offset, tag__natural_alignment(type, cu), smallest_offset); - smallest_offset = pos->byte_offset + pos->byte_size; + + /* Compute the smallest offset between this field and the next + * one. + * + * In case of bitfields we need to take into account the + * actual size being used instead of the underlying type one as + * it could be larger, otherwise we could miss a hole. + */ + smallest_offset = pos->byte_offset; + smallest_offset += pos->bitfield_size ? + (pos->bitfield_offset + pos->bitfield_size + 7) / 8 : + pos->byte_size; }
tag_type->alignment = class__infer_alignment(conf,
On Mon, Oct 27, 2025 at 12:09:11PM -0300, Arnaldo Carvalho de Melo wrote:
On Mon, Oct 27, 2025 at 11:58:43AM -0300, Arnaldo Carvalho de Melo wrote:
On Thu, Oct 23, 2025 at 08:42:34AM -0700, Alexei Starovoitov wrote:
On Thu, Oct 23, 2025 at 12:50 AM Jiayuan Chen jiayuan.chen@linux.dev wrote:
thanks, but version 1.30 didn't work in my tests - even pahole's master branch fails, only the next branch works...
It seems that the 'old' pahole parses some kfuncs incorrectly, for example bpf_dynptr_slice().
the introduction of the 'next' branch screwed up the workflow for many people. Let's remove it and merge everything into master. People expect master branch to be the one where active development is happening and the source of truth for the latest features.
My bad, I've been away for too long, next is supposed to be with things for a short while, testing for a few days, for CI consumption, then move to master, rinse repeat.
I think we should go back to that model.
The difference is small but can explain as has changes to the btf loader, and the reporter, as I now checked the whole thread, says that 'next' works for him, so I'll move what is in 'next' to 'master' now.
Just for reference since I had done it, my investigation is below.
So I had some random 'korg/next' local branch and a 'korg' remote and that messed up my analysis, there are more csets in the 'next' branch, so I'm doing more tests, tomorrow I'll probably have more news.
- Arnaldo
⬢ [acme@toolbx pahole]$ git remote update korg Fetching korg ⬢ [acme@toolbx pahole]$ ⬢ [acme@toolbx pahole]$ git remote -v | grep korg korg https://git.kernel.org/pub/scm/devel/pahole/pahole.git (fetch) korg https://git.kernel.org/pub/scm/devel/pahole/pahole.git (push) ⬢ [acme@toolbx pahole]$ git diff --stat korg/master korg/next warning: refname 'korg/next' is ambiguous. .github/scripts/build-pahole.sh | 23 +++++++++++++++++++++++ .github/scripts/compare-functions.sh | 30 ++++++++++++++++++++++++++++++ .github/workflows/test.yml | 4 ++-- .github/workflows/vmtest.yml | 4 ++++ CMakeLists.txt | 5 ----- README | 4 ++++ btf_loader.c | 23 ++++++++++++++++++++--- dwarves_fprintf.c | 2 +- 8 files changed, 84 insertions(+), 11 deletions(-) ⬢ [acme@toolbx pahole]$
Related to btf bitfields:
diff --git a/btf_loader.c b/btf_loader.c index f4f9f65289b5acac..64ea68022ab04e60 100644 --- a/btf_loader.c +++ b/btf_loader.c @@ -645,9 +645,15 @@ static int class__fixup_btf_bitfields(const struct conf_load *conf, struct tag * pos->byte_size = tag__size(type, cu); pos->bit_size = pos->byte_size * 8;
/* if BTF data is incorrect and has size == 0, skip field,* instead of crashing */
/* If the BTF data is incorrect and has size == 0, skip field* instead of crashing. However the field can be a zero or* variable-length array and we still need to infer alignment.*/ if (pos->byte_size == 0) {pos->alignment = class__infer_alignment(conf,pos->byte_offset,tag__natural_alignment(type, cu),smallest_offset); continue; }@@ -672,7 +678,18 @@ static int class__fixup_btf_bitfields(const struct conf_load *conf, struct tag * pos->byte_offset, tag__natural_alignment(type, cu), smallest_offset);
smallest_offset = pos->byte_offset + pos->byte_size;
/* Compute the smallest offset between this field and the next* one.** In case of bitfields we need to take into account the* actual size being used instead of the underlying type one as* it could be larger, otherwise we could miss a hole.*/smallest_offset = pos->byte_offset;smallest_offset += pos->bitfield_size ?(pos->bitfield_offset + pos->bitfield_size + 7) / 8 :pos->byte_size; }tag_type->alignment = class__infer_alignment(conf,
linux-kselftest-mirror@lists.linaro.org
-
Alexei Starovoitov -
Arnaldo Carvalho de Melo -
Jiayuan Chen -
Yonghong Song