Tags: brb/libbpf
Tags
libbpf: Add support for new llvm bpf relocations LLVM patch https://reviews.llvm.org/D102712 narrowed the scope of existing R_BPF_64_64 and R_BPF_64_32 relocations, and added three new relocations, R_BPF_64_ABS64, R_BPF_64_ABS32 and R_BPF_64_NODYLD32. The main motivation is to make relocations linker friendly. This change, unfortunately, breaks libbpf build, and we will see errors like below: libbpf: ELF relo #0 in section libbpf#6 has unexpected type 2 in /home/yhs/work/bpf-next/tools/testing/selftests/bpf/bpf_tcp_nogpl.o Error: failed to link '/home/yhs/work/bpf-next/tools/testing/selftests/bpf/bpf_tcp_nogpl.o': Unknown error -22 (-22) The new relocation R_BPF_64_ABS64 is generated and libbpf linker sanity check doesn't understand it. Relocation section '.rel.struct_ops' at offset 0x1410 contains 1 entries: Offset Info Type Symbol's Value Symbol's Name 0000000000000018 0000000700000002 R_BPF_64_ABS64 0000000000000000 nogpltcp_init Look at the selftests/bpf/bpf_tcp_nogpl.c, void BPF_STRUCT_OPS(nogpltcp_init, struct sock *sk) { } SEC(".struct_ops") struct tcp_congestion_ops bpf_nogpltcp = { .init = (void *)nogpltcp_init, .name = "bpf_nogpltcp", }; The new llvm relocation scheme categorizes 'nogpltcp_init' reference as R_BPF_64_ABS64 instead of R_BPF_64_64 which is used to specify ld_imm64 relocation in the new scheme. Let us fix the linker sanity checking by including R_BPF_64_ABS64 and R_BPF_64_ABS32. There is no need to check R_BPF_64_NODYLD32 which is used for .BTF and .BTF.ext. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20210522162341.3687617-1-yhs@fb.com
pkgconfig: use literal ${prefix} to allow override
Various workflows (--define-prefix, --define-variable=prefix) require variables in
the pc file to use a literal so that it is overridden. Change the Makefile
so that, by default and unless is specified, it is set as expected.
Signed-off-by: Luca Boccassi <bluca@debian.org>
libbpf: Fix XDP program load regression for old kernels
Fix regression in libbpf, introduced by XDP link change, which causes XDP
programs to fail to be loaded into kernel due to specified BPF_XDP
expected_attach_type. While kernel doesn't enforce expected_attach_type for
BPF_PROG_TYPE_XDP, some old kernels already support XDP program, but they
don't yet recognize expected_attach_type field in bpf_attr, so setting it to
non-zero value causes program load to fail.
Luckily, libbpf already has a mechanism to deal with such cases, so just make
expected_attach_type optional for XDP programs.
Fixes: dc8698cac7aa ("libbpf: Add support for BPF XDP link")
Reported-by: Nikita Shirokov <tehnerd@tehnerd.com>
Reported-by: Udip Pant <udippant@fb.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200924171705.3803628-1-andriin@fb.com
(cherry picked from commit 2200fef)
sync: latest libbpf changes from kernel
Syncing latest libbpf commits from kernel repository.
Baseline bpf-next commit: 69119673bd50b176ded34032fadd41530fb5af21
Checkpoint bpf-next commit: 4e15507fea70c0c312d79610efa46b6853ccf8e0
Baseline bpf commit: 6903cdae9f9f08d61e49c16cbef11c293e33a615
Checkpoint bpf commit: 4e15507fea70c0c312d79610efa46b6853ccf8e0
Andrii Nakryiko (1):
libbpf: Forward-declare bpf_stats_type for systems with outdated UAPI
headers
src/bpf.h | 2 ++
1 file changed, 2 insertions(+)
--
2.24.1
vmtest: build and run bpf kernel selftests against various kernels Run kernel selftests in vmtest with the goal to test libbpf backward compatibility with older kernels. The list of kernels should be specified in .travis.yml config in `jobs` section, e.g. KERNEL=5.5.0. Enlisted kernel releases - 5.5.0 # built from main - 5.5.0-rc6 # built from bpf-next - LATEST The kernel specified as 'LATEST' in .travis.yml is built from bpf-next kernel tree, the rest of the kernels are downloaded from the specified in INDEX file. The kernel sources from bpf-next are manually patched with [1] from bpf tree to fix ranqslower build. This workaround should be removed after the patch is merged from bpf to bpf-next tree. Due to kernel sources being checked out the duration of the LATEST kernel test is ~30m. bpf selftests are built from tools/testing/selftests/bpf/ of bpf-next tree with HEAD revision set to CHECKPOINT-COMMIT specified in libbpf so selftests and libbpf are in sync. Currently only programs are tested with test_progs program, test_maps and test_verifier should follow. test_progs are run with blacklist required due to: - some features, e.g. fentry/fexit are not supported in older kernels - environment limitations, e.g an absence of the recent pahole in Debian - incomplete disk image The blacklist is passed to test_progs with -b option as specified in [2] patch set. Most of the preceeding tests are disabled due to incomplete disk image currenly lacking proper networking settings. For the LATEST kernel fome fentry/fexit tests are disabled due to pahole v1.16 is not abailible in Debian yet. Next steps are resolving issues with blacklisted tests, enabling maps and verifier testing, expanding the list of tested kernels. [1] https://lore.kernel.org/bpf/908498f794661c44dca54da9e09dc0c382df6fcb.1580425879.git.hex@fb.com/t.mbox.gz [2] https://www.spinics.net/lists/netdev/msg625192.html
sync: latest libbpf changes from kernel Syncing latest libbpf commits from kernel repository. Baseline bpf-next commit: b615e5a1e067dcb327482d1af7463268b89b1629 Checkpoint bpf-next commit: e7096c131e5161fa3b8e52a650d7719d2857adfd Baseline bpf commit: 34e59836565e36fade1464e054a3551c1a0364be Checkpoint bpf commit: e42617b825f8073569da76dc4510bfa019b1c35a Alexei Starovoitov (2): libbpf: Fix sym->st_value print on 32-bit arches selftests/bpf: Add test for BPF trampoline Andrii Nakryiko (1): libbpf: Fix global variable relocation Martin KaFai Lau (1): bpf: Introduce BPF_TRACE_x helper for the tracing tests src/libbpf.c | 45 ++++++++++++++++++++------------------------- 1 file changed, 20 insertions(+), 25 deletions(-) -- 2.17.1
meson: kill meson.build as it's not used anymore Meson.build was added to facilitate systemd integration, but systemd integration went different direction and we don't need meson.build anymore. So remove it and not maintain it anymore. Signed-off-by: Andrii Nakryiko <andriin@fb.com>
PreviousNext