On Mon, May 23, 2022 at 1:18 AM Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> wrote: > > On Mon, May 23, 2022 at 04:11:27PM +0800, Shung-Hsi Yu wrote: > > On Thu, May 19, 2022 at 08:25:00AM -0700, Vincent Li wrote: > > > Hi, > > > > > > Here is my step to run bpf selftest on Ubuntu 20.04.2 LTS > > > > > > git clone https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git > > > cd bpf-next; cp /boot/config-5.10.0-051000-generic .config; yes "" | > > > make oldconfig; make bzImage; make modules; cd > > > tools/testing/selftests/bpf/; make > > > > [snip...] > > > > > ; bpf_printk("vxlan key %d local ip 0x%x remote ip 0x%x gbp 0x%x\n", > > > > > > 46: (7b) *(u64 *)(r10 -88) = r2 > > > > > > 47: (7b) *(u64 *)(r10 -72) = r1 > > > > > > 48: (61) r1 = *(u32 *)(r10 -48) > > > > > > 49: (7b) *(u64 *)(r10 -96) = r1 > > > > > > 50: (61) r1 = *(u32 *)(r10 -44) > > > > > > 51: (7b) *(u64 *)(r10 -80) = r1 > > > > > > 52: (bf) r3 = r10 > > > > > > 53: (07) r3 += -96 > > > > > > 54: (18) r1 = 0xffffabaec02c82af > > > > > > 56: (b4) w2 = 52 > > > > > > 57: (b4) w4 = 32 > > > > > > 58: (85) call unknown#177 > > > > > > invalid func unknown#177 > > > > This should be the reason that why vxlan_get_tunnel_src fails to load, the > > kernel does not recognize the helper function that the program is trying to > > call. > > Just realized Andrii already pointed this out in an earlier email. Consider > this an expanded answer to his then :) > Thank you both for the answer, I was wondering where the number #177 came from, you answered it :) > > And that helper function is bpf_trace_vprintk (determined with v5.17.4 > > vmlinux). > > > > $ bpftool btf dump file /sys/kernel/btf/vmlinux format c | grep -e 'BPF_FUNC_.* 177,' > > BPF_FUNC_trace_vprintk = 177, > > > > Based on your description you're using a v5.10-based kernel, which explains > > why it doesn't have bpf_trace_vprintk(), since it was not added until commit > > 10aceb629e19 ("bpf: Add bpf_trace_vprintk helper") in v5.16. > > > > The call to bpf_trace_vprintk() comes from the bpf_printk() call, which is > > actually a macro that uses either bpf_trace_printk() or bpf_trace_vprintk() > > depending on the number of arguments given[1]. > > > > In general I think it'd make more sense to run bpf-next selftests on a > > bpf-next kernel, either compile and install on the machine that you're > > testing on or use tools/testing/selftests/bpf/vmtest.sh which spins up a VM > > with suitable environment (though I haven't tried vmtest.sh myself). > > > > > > Shung-Hsi > > > > 1: https://github.com/libbpf/libbpf/blob/master/src/bpf_helpers.h > > > > > processed 64 insns (limit 1000000) max_states_per_insn 1 total_states > > > 5 peak_states 5 mark_read 2 > > > > > > -- END PROG LOAD LOG -- > > > > > > libbpf: failed to load program 'vxlan_get_tunnel_src' > > > > > > libbpf: failed to load object 'test_tunnel_kern' > > > > > > libbpf: failed to load BPF skeleton 'test_tunnel_kern': -22 > > > > > > test_ip6vxlan_tunnel:FAIL:test_tunnel_kern__open_and_load unexpected error: -22 > > > > > > serial_test_tunnel:PASS:pthread_join 0 nsec > > > > > > #198/2 tunnel/ip6vxlan_tunnel:FAIL > > > > > > #198 tunnel:FAIL > > > > > > Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED > > > > > > > >
