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
