Eduard Zingerman <eddyz87@xxxxxxxxx> writes: > On Tue, 2025-02-11 at 16:49 -0800, Stephen Brennan wrote: > > [...] > >> I've gone ahead and tested this by building & booting a kernel with these >> changes, and the kernel patch series at [1]. The result exhibited no BPF >> varidation errors, and the drgn BTF branch[2] is working perfectly with it! > > I tried out this patch-set: > - applied it to pahole; > - applied [1] to kernel; > - configured kernel as in [2] to run BPF selftests. > > With this all done none of BPF selftests could be run. > E.g. doing './test_progs -vvv -n 1' gets me the following error: > > libbpf: Error in bpf_object__probe_loading(): -EINVAL. Couldn't load trivial BPF program. Make sure your kernel supports BPF (CONFIG_BPF_SYSCALL=y) and/or that RLIMIT_MEMLOCK is set to big enough value. > > If libbpf is hacked to print verifier log for > bpf_object__probe_loading, the log looks as follows: > > in-kernel BTF is malformed > processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 > > BTF is broken in some nasty way, as nothing is printed to dmesg, > even if I add some printk's inside bpf_get_btf_vmlinux(). > All I can see is that 'btf_vmlinux' is set to 0xffffffffffffffea very > early in the boot process. > > [1] https://lore.kernel.org/bpf/20250207012045.2129841-1-stephen.s.brennan@xxxxxxxxxx/ > [2] https://gist.github.com/eddyz87/5282db54255b81eed731b955dc5ea690 Thank you for the testing (and the review). I haven't yet been able to reproduce this. But I see you're using clang. I'll spend the morning building & running selftests with clang to see whether that is the issue. Thanks, Stephen
