- 12 Nov, 2021 14 commits
-
-
Yonghong Song authored
LLVM patches ([1] for clang, [2] and [3] for BPF backend) added support for btf_type_tag attributes. This patch added support for the kernel. The main motivation for btf_type_tag is to bring kernel annotations __user, __rcu etc. to btf. With such information available in btf, bpf verifier can detect mis-usages and reject the program. For example, for __user tagged pointer, developers can then use proper helper like bpf_probe_read_user() etc. to read the data. BTF_KIND_TYPE_TAG may also useful for other tracing facility where instead of to require user to specify kernel/user address type, the kernel can detect it by itself with btf. [1] https://reviews.llvm.org/D111199 [2] https://reviews.llvm.org/D113222 [3] https://reviews.llvm.org/D113496Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211112012609.1505032-1-yhs@fb.com
-
Alexei Starovoitov authored
Andrii Nakryiko says: ==================== This patch set continues the work of revamping libbpf APIs that are not extensible, as they were added before we figured out all the intricacies of building APIs that can preserve ABI compatibility (both backward and forward). What makes them tricky is that (most of) these APIs are actively used by multiple applications, so we need to be careful about refactoring them. See individual patches for details, but the general approach is similar to previous bpf_prog_load() API revamp. The biggest different and complexity is in changing btf_dump__new(), because function overloading through macro magic doesn't work based on number of arguments, as both new and old APIs have 4 arguments. Because of that, another overloading approach is taken; overload happens based on argument types. I've validated manually (by using local test_progs-shared flavor that is compiling test_progs against libbpf as a shared library) that compiling "old application" (selftests before being adapted to using new variants of revamped APIs) are compiled and successfully run against newest libbpf version as well as the older libbpf version (provided no new variants are used). All these scenarios seem to be working as expected. v1->v2: - add explicit printf_fn NULL check in btf_dump__new() (Alexei); - replaced + with || in __builtin_choose_expr() (Alexei); - dropped test_progs-shared flavor (Alexei). ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Andrii Nakryiko authored
Use v1.0-compatible variants of btf_dump and perf_buffer "constructors". This is also a demonstration of reusing struct perf_buffer_raw_opts as OPTS-style option struct for new perf_buffer__new_raw() API. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111053624.190580-10-andrii@kernel.org
-
Andrii Nakryiko authored
Use v1.0+ compatible variant of perf_buffer__new() call to prepare for deprecation. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111053624.190580-9-andrii@kernel.org
-
Andrii Nakryiko authored
Update to-be-deprecated forms of btf_dump__new(). Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111053624.190580-8-andrii@kernel.org
-
Andrii Nakryiko authored
Migrate all old-style perf_buffer__new() and perf_buffer__new_raw() calls to new v1.0+ variants. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111053624.190580-7-andrii@kernel.org
-
Andrii Nakryiko authored
Add new variants of perf_buffer__new() and perf_buffer__new_raw() that use OPTS-based options for future extensibility ([0]). Given all the currently used API names are best fits, re-use them and use ___libbpf_override() approach and symbol versioning to preserve ABI and source code compatibility. struct perf_buffer_opts and struct perf_buffer_raw_opts are kept as well, but they are restructured such that they are OPTS-based when used with new APIs. For struct perf_buffer_raw_opts we keep few fields intact, so we have to also preserve the memory location of them both when used as OPTS and for legacy API variants. This is achieved with anonymous padding for OPTS "incarnation" of the struct. These pads can be eventually used for new options. [0] Closes: https://github.com/libbpf/libbpf/issues/311Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111053624.190580-6-andrii@kernel.org
-
Andrii Nakryiko authored
Change btf_dump__new() and corresponding struct btf_dump_ops structure to be extensible by using OPTS "framework" ([0]). Given we don't change the names, we use a similar approach as with bpf_prog_load(), but this time we ended up with two APIs with the same name and same number of arguments, so overloading based on number of arguments with ___libbpf_override() doesn't work. Instead, use "overloading" based on types. In this particular case, print callback has to be specified, so we detect which argument is a callback. If it's 4th (last) argument, old implementation of API is used by user code. If not, it must be 2nd, and thus new implementation is selected. The rest is handled by the same symbol versioning approach. btf_ext argument is dropped as it was never used and isn't necessary either. If in the future we'll need btf_ext, that will be added into OPTS-based struct btf_dump_opts. struct btf_dump_opts is reused for both old API and new APIs. ctx field is marked deprecated in v0.7+ and it's put at the same memory location as OPTS's sz field. Any user of new-style btf_dump__new() will have to set sz field and doesn't/shouldn't use ctx, as ctx is now passed along the callback as mandatory input argument, following the other APIs in libbpf that accept callbacks consistently. Again, this is quite ugly in implementation, but is done in the name of backwards compatibility and uniform and extensible future APIs (at the same time, sigh). And it will be gone in libbpf 1.0. [0] Closes: https://github.com/libbpf/libbpf/issues/283Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111053624.190580-5-andrii@kernel.org
-
Andrii Nakryiko authored
btf__dedup() and struct btf_dedup_opts were added before we figured out OPTS mechanism. As such, btf_dedup_opts is non-extensible without breaking an ABI and potentially crashing user application. Unfortunately, btf__dedup() and btf_dedup_opts are short and succinct names that would be great to preserve and use going forward. So we use ___libbpf_override() macro approach, used previously for bpf_prog_load() API, to define a new btf__dedup() variant that accepts only struct btf * and struct btf_dedup_opts * arguments, and rename the old btf__dedup() implementation into btf__dedup_deprecated(). This keeps both source and binary compatibility with old and new applications. The biggest problem was struct btf_dedup_opts, which wasn't OPTS-based, and as such doesn't have `size_t sz;` as a first field. But btf__dedup() is a pretty rarely used API and I believe that the only currently known users (besides selftests) are libbpf's own bpf_linker and pahole. Neither use case actually uses options and just passes NULL. So instead of doing extra hacks, just rewrite struct btf_dedup_opts into OPTS-based one, move btf_ext argument into those opts (only bpf_linker needs to dedup btf_ext, so it's not a typical thing to specify), and drop never used `dont_resolve_fwds` option (it was never used anywhere, AFAIK, it makes BTF dedup much less useful and efficient). Just in case, for old implementation, btf__dedup_deprecated(), detect non-NULL options and error out with helpful message, to help users migrate, if there are any user playing with btf__dedup(). The last remaining piece is dedup_table_size, which is another anachronism from very early days of BTF dedup. Since then it has been reduced to the only valid value, 1, to request forced hash collisions. This is only used during testing. So instead introduce a bool flag to force collisions explicitly. This patch also adapts selftests to new btf__dedup() and btf_dedup_opts use to avoid selftests breakage. [0] Closes: https://github.com/libbpf/libbpf/issues/281Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111053624.190580-4-andrii@kernel.org
-
Andrii Nakryiko authored
Few clean ups and single-line simplifications. Also split CLEAN command into multiple $(RM) invocations as it gets dangerously close to too long argument list. Make sure that -o <output.o> is used always as the last argument for saner verbose make output. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111053624.190580-3-andrii@kernel.org
-
Andrii Nakryiko authored
When dealing with verbose Makefile output, it's extremely confusing when compiler invocation commands don't specify -o <output.o> as the last argument. Normalize bpftool's Makefile to do just that, as most other BPF-related Makefiles are already doing that. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111053624.190580-2-andrii@kernel.org
-
Alexei Starovoitov authored
Andrii Nakryiko says: ==================== Fix the ability to request verbose (log_level=1) or very verbose (log_level=2) logs with test_progs's -vv or -vvv parameters. This ability regressed during recent bpf_prog_load() API refactoring. Also add bpf_program__set_extra_flags() API to allow setting extra testing flags (BPF_F_TEST_RND_HI32), which was also dropped during recent changes. ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Andrii Nakryiko authored
After recent refactoring bpf_prog_test_load(), used across multiple selftests, lost ability to specify extra log_level 1 or 2 (for -vv and -vvv, respectively). Fix that problem by using bpf_object__load_xattr() API that supports extra log_level flags. Also restore BPF_F_TEST_RND_HI32 prog_flags by utilizing new bpf_program__set_extra_flags() API. Fixes: f87c1930 ("selftests/bpf: Merge test_stub.c into testing_helpers.c") Reported-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111051758.92283-3-andrii@kernel.org
-
Andrii Nakryiko authored
Add bpf_program__flags() API to retrieve prog_flags that will be (or were) supplied to BPF_PROG_LOAD command. Also add bpf_program__set_extra_flags() API to allow to set *extra* flags, in addition to those determined by program's SEC() definition. Such flags are logically OR'ed with libbpf-derived flags. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211111051758.92283-2-andrii@kernel.org
-
- 11 Nov, 2021 3 commits
-
-
Alexei Starovoitov authored
Mark Pashmfouroush says: ==================== BPF_SK_LOOKUP users may want to have access to the ifindex of the skb which triggered the socket lookup. This may be useful for selectively applying programmable socket lookup logic to packets that arrive on a specific interface, or excluding packets from an interface. v3: - Rename ifindex field to ingress_ifindex for consistency. (Yonghong) v2: - Fix inaccurate comment (Alexei) - Add more details to commit messages (John) ==================== Revieview-by: Lorenz Bauer <lmb@cloudflare.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Mark Pashmfouroush authored
A new field was added to the bpf_sk_lookup data that users can access. Add tests that validate that the new ingress_ifindex field contains the right data. Signed-off-by: Mark Pashmfouroush <markpash@cloudflare.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211110111016.5670-3-markpash@cloudflare.com
-
Mark Pashmfouroush authored
It may be helpful to have access to the ifindex during bpf socket lookup. An example may be to scope certain socket lookup logic to specific interfaces, i.e. an interface may be made exempt from custom lookup code. Add the ifindex of the arriving connection to the bpf_sk_lookup API. Signed-off-by: Mark Pashmfouroush <markpash@cloudflare.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211110111016.5670-2-markpash@cloudflare.com
-
- 10 Nov, 2021 1 commit
-
-
Quentin Monnet authored
Bpftool is dual-licensed under GPLv2 and BSD-2-Clause. In commit 907b2236 ("tools: bpftool: dual license all files") we made sure that all its source files were indeed covered by the two licenses, and that they had the correct SPDX tags. However, bpftool's Makefile, the Makefile for its documentation, and the .gitignore file were skipped at the time (their GPL-2.0-only tag was added later). Let's update the tags. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Tobias Klauser <tklauser@distanz.ch> Acked-by: Joe Stringer <joe@cilium.io> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/bpf/20211105221904.3536-1-quentin@isovalent.com
-
- 09 Nov, 2021 1 commit
-
-
Kumar Kartikeya Dwivedi authored
The minimum supported C standard version is C89, with use of GNU extensions, hence make sure to catch any instances that would break the build for this mode by passing -std=gnu89. Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211105234243.390179-4-memxor@gmail.com
-
- 08 Nov, 2021 2 commits
-
-
Alan Maguire authored
Exception handling is triggered in BPF tracing programs when a NULL pointer is dereferenced; the exception handler zeroes the target register and execution of the BPF program progresses. To test exception handling then, we need to trigger a NULL pointer dereference for a field which should never be zero; if it is, the only explanation is the exception handler ran. task->task_works is the NULL pointer chosen (for a new task from fork() no work is associated), and the task_works->func field should not be zero if task_works is non-NULL. The test verifies that task_works and task_works->func are 0. Signed-off-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/1636131046-5982-3-git-send-email-alan.maguire@oracle.com
-
Russell King authored
Commit 91fc957c ("arm64/bpf: don't allocate BPF JIT programs in module memory") restricts BPF JIT program allocation to a 128MB region to ensure BPF programs are still in branching range of each other. However this restriction should not apply to the aarch64 JIT, since BPF_JMP | BPF_CALL are implemented as a 64-bit move into a register and then a BLR instruction - which has the effect of being able to call anything without proximity limitation. The practical reason to relax this restriction on JIT memory is that 128MB of JIT memory can be quickly exhausted, especially where PAGE_SIZE is 64KB - one page is needed per program. In cases where seccomp filters are applied to multiple VMs on VM launch - such filters are classic BPF but converted to BPF - this can severely limit the number of VMs that can be launched. In a world where we support BPF JIT always on, turning off the JIT isn't always an option either. Fixes: 91fc957c ("arm64/bpf: don't allocate BPF JIT programs in module memory") Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <russell.king@oracle.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Alan Maguire <alan.maguire@oracle.com> Link: https://lore.kernel.org/bpf/1636131046-5982-2-git-send-email-alan.maguire@oracle.com
-
- 07 Nov, 2021 19 commits
-
-
Alexei Starovoitov authored
Song Liu says: ==================== Changes v4 => v5: 1. Clean up and style change in 2/2. (Andrii) Changes v3 => v4: 1. Move mmap_unlock_work to task_iter.c to fix build for .config without !CONFIG_PERF_EVENTS. (kernel test robot <lkp@intel.com>) Changes v2 => v3: 1. Avoid using x86 only function in selftests. (Yonghong) 2. Add struct file and struct vm_area_struct to btf_task_struct_ids, and use it in bpf_find_vma and stackmap.c. (Yonghong) 3. Fix inaccurate comments. (Yonghong) Changes v1 => v2: 1. Share irq_work with stackmap.c. (Daniel) 2. Add tests for illegal writes to task/vma from the callback function. (Daniel) 3. Other small fixes. Add helper bpf_find_vma. This can be used in some profiling use cases. It might also be useful for LSM. ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Song Liu authored
Add tests for bpf_find_vma in perf_event program and kprobe program. The perf_event program is triggered from NMI context, so the second call of bpf_find_vma() will return -EBUSY (irq_work busy). The kprobe program, on the other hand, does not have this constraint. Also add tests for illegal writes to task or vma from the callback function. The verifier should reject both cases. Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20211105232330.1936330-3-songliubraving@fb.com
-
Song Liu authored
In some profiler use cases, it is necessary to map an address to the backing file, e.g., a shared library. bpf_find_vma helper provides a flexible way to achieve this. bpf_find_vma maps an address of a task to the vma (vm_area_struct) for this address, and feed the vma to an callback BPF function. The callback function is necessary here, as we need to ensure mmap_sem is unlocked. It is necessary to lock mmap_sem for find_vma. To lock and unlock mmap_sem safely when irqs are disable, we use the same mechanism as stackmap with build_id. Specifically, when irqs are disabled, the unlocked is postponed in an irq_work. Refactor stackmap.c so that the irq_work is shared among bpf_find_vma and stackmap helpers. Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Tested-by: Hengqi Chen <hengqi.chen@gmail.com> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20211105232330.1936330-2-songliubraving@fb.com
-
Alexei Starovoitov authored
Andrii Nakryiko says: ==================== Fix all the memory leaks reported by ASAN. All but one are just improper resource clean up in selftests. But one memory leak was discovered in libbpf, leaving inner map's name leaked. First patch fixes selftests' Makefile by passing through SAN_CFLAGS to linker. Without that compiling with SAN_CFLAGS=-fsanitize=address kept failing. Running selftests under ASAN in BPF CI is the next step, we just need to make sure all the necessary libraries (libasan and liblsan) are installed on the host and inside the VM. Would be great to get some help with that, but for now make sure that test_progs run is clean from leak sanitizer errors. v3->v4: - rebase on latest bpf-next; v2->v3: - fix per-cpu array memory leaks in btf_iter.c selftests (Hengqi); v1->v2: - call bpf_map__destroy() conditionally if map->inner_map is present. ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Andrii Nakryiko authored
skb_ctx selftest didn't close bpf_object implicitly allocated by bpf_prog_test_load() helper. Fix the problem by explicitly calling bpf_object__close() at the end of the test. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com> Link: https://lore.kernel.org/bpf/20211107165521.9240-10-andrii@kernel.org
-
Andrii Nakryiko authored
bpf_link__detach() was confused with bpf_link__destroy() and leaves leaked FD in the process. Fix the problem. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com> Link: https://lore.kernel.org/bpf/20211107165521.9240-9-andrii@kernel.org
-
Andrii Nakryiko authored
btf__parse() is repeated after successful setup, leaving the first instance leaked. Remove redundant and premature call. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com> Link: https://lore.kernel.org/bpf/20211107165521.9240-8-andrii@kernel.org
-
Andrii Nakryiko authored
Free up used resources at the end and on error. Also make it more obvious that there is btf__parse() call that creates struct btf instance. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com> Link: https://lore.kernel.org/bpf/20211107165521.9240-7-andrii@kernel.org
-
Andrii Nakryiko authored
Inner array of allocated strings wasn't freed on success. Now it's always freed. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com> Link: https://lore.kernel.org/bpf/20211107165521.9240-6-andrii@kernel.org
-
Andrii Nakryiko authored
Array holding per-cpu values wasn't freed. Fix that. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211107165521.9240-5-andrii@kernel.org
-
Andrii Nakryiko authored
Free up memory and resources used by temporary allocated memstream and btf_dump instance. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com> Link: https://lore.kernel.org/bpf/20211107165521.9240-4-andrii@kernel.org
-
Andrii Nakryiko authored
It's not enough to just free(map->inner_map), as inner_map itself can have extra memory allocated, like map name. Fixes: 646f02ff ("libbpf: Add BTF-defined map-in-map support") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com> Link: https://lore.kernel.org/bpf/20211107165521.9240-3-andrii@kernel.org
-
Andrii Nakryiko authored
When adding -fsanitize=address to SAN_CFLAGS, it has to be passed both to compiler through CFLAGS as well as linker through LDFLAGS. Add SAN_CFLAGS into LDFLAGS to allow building selftests with ASAN. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com> Link: https://lore.kernel.org/bpf/20211107165521.9240-2-andrii@kernel.org
-
Alexei Starovoitov authored
Andrii Nakryiko says: ==================== This patch set adds unified OPTS-based low-level bpf_prog_load() API for loading BPF programs directly into kernel without utilizing libbpf's bpf_object abstractions. This OPTS-based interface allows for future extensions without breaking backwards or forward API and ABI compatibility. Similar approach will be used for other low-level APIs that require extensive sets of parameters, like BPF_MAP_CREATE command. First half of the patch set adds libbpf API, cleans up internal usage of to-be-deprecated APIs, etc. Second half cleans up and converts selftests away from using deprecated APIs. See individual patches for more details. v1->v2: - dropped exposing sys_bpf() into public API (Alexei, Daniel); - also dropped bpftool/cgroup.c fix for unistd.h include because it's not necessary due to sys_bpf() staying as is. Cc: Hengqi Chen <hengqi.chen@gmail.com> ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Andrii Nakryiko authored
Remove the second part of prog loading testing helper re-definition: -Dbpf_load_program=bpf_test_load_program This completes the clean up of deprecated libbpf program loading APIs. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Dave Marchevsky <davemarchevsky@fb.com> Link: https://lore.kernel.org/bpf/20211103220845.2676888-13-andrii@kernel.org
-
Andrii Nakryiko authored
-Dbpf_prog_load_deprecated=bpf_prog_test_load trick is both ugly and breaks when deprecation goes into effect due to macro magic. Convert all the uses to explicit bpf_prog_test_load() calls which avoid deprecation errors and makes everything less magical. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Dave Marchevsky <davemarchevsky@fb.com> Link: https://lore.kernel.org/bpf/20211103220845.2676888-12-andrii@kernel.org
-
Andrii Nakryiko authored
Move testing prog and object load wrappers (bpf_prog_test_load and bpf_test_load_program) into testing_helpers.{c,h} and get rid of otherwise useless test_stub.c. Make testing_helpers.c available to non-test_progs binaries as well. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Dave Marchevsky <davemarchevsky@fb.com> Link: https://lore.kernel.org/bpf/20211103220845.2676888-11-andrii@kernel.org
-
Andrii Nakryiko authored
Convert all the uses of legacy low-level BPF program loading APIs (mostly bpf_load_program_xattr(), but also some bpf_verify_program()) to bpf_prog_load() uses. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211103220845.2676888-10-andrii@kernel.org
-
Andrii Nakryiko authored
Fix few more SEC() definitions that were previously missed. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Dave Marchevsky <davemarchevsky@fb.com> Link: https://lore.kernel.org/bpf/20211103220845.2676888-9-andrii@kernel.org
-