- 21 Oct, 2019 7 commits
-
-
Andrii Nakryiko authored
test_progs never created a copy of subtest name, rather just stored pointer to whatever string test provided. This is bad as that string might be freed or modified by the end of subtest. Fix this by creating a copy of given subtest name when subtest starts. Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191021033902.3856966-6-andriin@fb.com
-
Andrii Nakryiko authored
Teach bpf_object__open how to guess program type and expected attach type from section names, similar to what bpf_prog_load() does. This seems like a really useful features and an oversight to not have this done during bpf_object_open(). To preserver backwards compatible behavior of bpf_prog_load(), its attr->prog_type is treated as an override of bpf_object__open() decisions, if attr->prog_type is not UNSPECIFIED. There is a slight difference in behavior for bpf_prog_load(). Previously, if bpf_prog_load() was loading BPF object with more than one program, first program's guessed program type and expected attach type would determine corresponding attributes of all the subsequent program types, even if their sections names suggest otherwise. That seems like a rather dubious behavior and with this change it will behave more sanely: each program's type is determined individually, unless they are forced to uniformity through attr->prog_type. Signed-off-by:
-
Andrii Nakryiko authored
Map uprobe/uretprobe into KPROBE program type. tp/raw_tp are just an alias for more verbose tracepoint/raw_tracepoint, respectively. Signed-off-by:
-
Andrii Nakryiko authored
There are bpf_program__set_type() and bpf_program__set_expected_attach_type(), but no corresponding getters, which seems rather incomplete. Fix this. Signed-off-by:
-
Andrii Nakryiko authored
Sync if_link.h into tools/ and get rid of annoying libbpf Makefile warning. Signed-off-by:
-
Kefeng Wang authored
For kernel logging macros, pr_warning() is completely removed and replaced by pr_warn(). By using pr_warn() in tools/lib/bpf/ for symmetry to kernel logging macros, we could eventually drop the use of pr_warning() in the whole kernel tree. Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Acked-by:
-
Jakub Sitnicki authored
Don't generate a broken bpf_helper_defs.h header if the helper script needs updating because it doesn't recognize a newly added type. Instead print an error that explains why the build is failing, clean up the partially generated header and stop. v1->v2: - Switched from temporary file to .DELETE_ON_ERROR. Fixes: 456a513b ("scripts/bpf: Emit an #error directive known types list needs updating") Suggested-by:
Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Yonghong Song <yhs@fb.com> Acked-by:
-
- 18 Oct, 2019 3 commits
-
-
John Fastabend authored
With commit "libbpf: stop enforcing kern_version,..." we removed the kernel version section parsing in favor of querying for the kernel using uname() and populating the version using the result of the query. After this any version sections were simply ignored. Unfortunately, the world of kernels is not so friendly. I've found some customized kernels where uname() does not match the in kernel version. To fix this so programs can load in this environment this patch adds back parsing the section and if it exists uses the user specified kernel version to override the uname() result. However, keep most the kernel uname() discovery bits so users are not required to insert the version except in these odd cases. Fixes: 5e61f270 ("libbpf: stop enforcing kern_version, populate it for users") Signed-off-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
-
YueHaibing authored
If CONFIG_NET is n, building fails: kernel/trace/bpf_trace.o: In function `raw_tp_prog_func_proto': bpf_trace.c:(.text+0x1a34): undefined reference to `bpf_skb_output_proto' Wrap it into a #ifdef to fix this. Fixes: a7658e1a ("bpf: Check types of arguments passed into helpers") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Alexei Starovoitov authored
Only raw_tracepoint program type can have bpf_attr.attach_btf_id >= 0. Make sure to reject other program types that accidentally set it to non-zero. Fixes: ccfe29eb ("bpf: Add attach_btf_id attribute to program load") Reported-by:
-
- 17 Oct, 2019 21 commits
-
-
Alexei Starovoitov authored
Andrii Nakryiko says: ==================== This patch set extensively revamps selftests/bpf's Makefile to generalize test runner concept and apply it uniformly to test_maps and test_progs test runners, along with test_progs' few build "flavors", exercising various ways to build BPF programs. As we do that, we fix dependencies between various phases of test runners, and simplify some one-off rules and dependencies currently present in Makefile. test_progs' flavors are now built into root $(OUTPUT) directory and can be run without any extra steps right from there. E.g., test_progs-alu32 is built and is supposed to be run from $(OUTPUT). It will cd into alu32/ subdirectory to load correct set of BPF object files (which are different from the ones built for test_progs). Outline: - patch #1 teaches test_progs about flavor sub-directories; - patch #2 fixes one of CO-RE tests to not depend strictly on process name; - patch #3 changes test_maps's usage of map_tests/tests.h to be the same as test_progs' one; - patch #4 adds convenient short `make test_progs`-like targets to build only individual tests, if necessary; - patch #5 is a main patch in the series; it uses a bunch of make magic (mainly $(call) and $(eval)) to define test runner "skeleton" and apply it to 4 different test runners, lots more details in corresponding commit description; - patch #6 does a bit of post-clean up for test_queue_map and test_stack_map BPF programs; - patch #7 cleans up test_libbpf.sh/test_libbpf_open superseded by test_progs. v3->v4: - remove accidentally checked in binaries; v2->v3: - drop test_xdp.o mixed compilation mode, remove test_libbpf.sh (Alexei); v1->v2: - drop test_progs-native causing compilation failures due to __builtin_preserve_field_access, add back test_xdp.o override, which will now emit rule re-definition warning. ==================== Signed-off-by: -
Andrii Nakryiko authored
test_progs is much more sophisticated superset of tests compared to test_libbpf.sh and test_libbpf_open. Remove test_libbpf.sh and test_libbpf_open. Signed-off-by:
-
Andrii Nakryiko authored
test_queue_stack_map.h is used only from BPF programs. Thus it should be part of progs/ subdir. An added benefit of moving it there is that new TEST_RUNNER_DEFINE_RULES macro-rule will properly capture dependency on this header for all BPF objects and trigger re-build, if it changes. Signed-off-by:
-
Andrii Nakryiko authored
Define test runner generation meta-rule that codifies dependencies between test runner, its tests, and its dependent BPF programs. Use that for defining test_progs and test_maps test-runners. Also additionally define 2 flavors of test_progs: - alu32, which builds BPF programs with 32-bit registers codegen; - bpf_gcc, which build BPF programs using GCC, if it supports BPF target. Overall, this is accomplished through $(eval)'ing a set of generic rules, which defines Makefile targets dynamically at runtime. See comments explaining the need for 2 $(evals), though. For each test runner we have (test_maps and test_progs, currently), and, optionally, their flavors, the logic of build process is modeled as follows (using test_progs as an example): - all BPF objects are in progs/: - BPF object's .o file is built into output directory from corresponding progs/.c file; - all BPF objects in progs/*.c depend on all progs/*.h headers; - all BPF objects depend on bpf_*.h helpers from libbpf (but not libbpf archive). There is an extra rule to trigger bpf_helper_defs.h (re-)build, if it's not present/outdated); - build recipe for BPF object can be re-defined per test runner/flavor; - test files are built from prog_tests/*.c: - all such test file objects are built on individual file basis; - currently, every single test file depends on all BPF object files; this might be improved in follow up patches to do 1-to-1 dependency, but allowing to customize this per each individual test; - each test runner definition can specify a list of extra .c and .h files to be built along test files and test runner binary; all such headers are becoming automatic dependency of each test .c file; - due to test files sometimes embedding (using .incbin assembly directive) contents of some BPF objects at compilation time, which are expected to be in CWD of compiler, compilation for test file object does cd into test runner's output directory; to support this mode all the include paths are turned into absolute paths using $(abspath) make function; - prog_tests/test.h is automatically (re-)generated with an entry for each .c file in prog_tests/; - final test runner binary is linked together from test object files and extra object files, linking together libbpf's archive as well; - it's possible to specify extra "resource" files/targets, which will be copied into test runner output directory, if it differes from Makefile-wide $(OUTPUT). This is used to ensure btf_dump test cases and urandom_read binary is put into a test runner's CWD for tests to find them in runtime. For flavored test runners, their output directory is a subdirectory of common Makefile-wide $(OUTPUT) directory with flavor name used as subdirectory name. BPF objects targets might be reused between different test runners, so extra checks are employed to not double-define them. Similarly, we have redefinition guards for output directories and test headers. test_verifier follows slightly different patterns and is simple enough to not justify generalizing TEST_RUNNER_DEFINE/TEST_RUNNER_DEFINE_RULES further to accomodate these differences. Instead, rules for test_verifier are minimized and simplified, while preserving correctness of dependencies. Signed-off-by: -
Andrii Nakryiko authored
Currently it's impossible to do `make test_progs` and have only test_progs be built, because all the binary targets are defined in terms of $(OUTPUT)/<binary>, and $(OUTPUT) is absolute path to current directory (or whatever gets overridden to by user). This patch adds simple re-directing targets for all test targets making it possible to do simple and nice `make test_progs` (and any other target). Signed-off-by:
-
Andrii Nakryiko authored
Make test_maps use tests.h header format consistent with the one used by test_progs, to facilitate unification. Signed-off-by:
-
Andrii Nakryiko authored
test_core_reloc_kernel test captures its own process name and validates it as part of the test. Given extra "flavors" of test_progs, this break for anything by default test_progs binary. Fix the test to cut out flavor part of the process name. Fixes: ee2eb063 ("selftests/bpf: Add BPF_CORE_READ and BPF_CORE_READ_STR_INTO macro tests") Signed-off-by:
-
Andrii Nakryiko authored
We are building a bunch of "flavors" of test_progs, e.g., w/ alu32 flag for Clang when building BPF object. test_progs setup is relying on having all the BPF object files and extra resources to be available in current working directory, though. But we actually build all these files into a separate sub-directory. Next set of patches establishes convention of naming "flavored" test_progs (and test runner binaries in general) as test_progs-flavor (e.g., test_progs-alu32), for each such extra flavor. This patch teaches test_progs binary to automatically detect its own extra flavor based on its argv[0], and if present, to change current directory to a flavor-specific subdirectory. Signed-off-by:
-
Jakub Sitnicki authored
flow_dissector_reattach test changes the netns we run in but does not restore it to the one we started in when finished. This interferes with tests that run after it. Fix it by restoring the netns when done. Fixes: f97eea17 ("selftests/bpf: Check that flow dissector can be re-attached") Reported-by:
Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20191017083752.30999-1-jakub@cloudflare.com
-
Daniel Borkmann authored
Alexei Starovoitov says: ==================== v2->v3: - while trying to adopt btf-based tracing in production service realized that disabling bpf_probe_read() was premature. The real tracing program needs to see much more than this type safe tracking can provide. With these patches the verifier will be able to see that skb->data is a pointer to 'u8 *', but it cannot possibly know how many bytes of it is readable. Hence bpf_probe_read() is necessary to do basic packet reading from tracing program. Some helper can be introduced to solve this particular problem, but there are other similar structures. Another issue is bitfield reading. The support for bitfields is coming to llvm. libbpf will be supporting it eventually as well, but there will be corner cases where bpf_probe_read() is necessary. The long term goal is still the same: get rid of probe_read eventually. - fixed build issue with clang reported by Nathan Chancellor. - addressed a ton of comments from Andrii. bitfields and arrays are explicitly unsupported in btf-based tracking. This will be improved in the future. Right now the verifier is more strict than necessary. In some cases it can fall back to 'scalar' instead of rejecting the program, but rejection today allows to make better decisions in the future. - adjusted testcase to demo bitfield and skb->data reading. v1->v2: - addressed feedback from Andrii and Eric. Thanks a lot for review! - added missing check at raw_tp attach time. - Andrii noticed that expected_attach_type cannot be reused. Had to introduce new field to bpf_attr. - cleaned up logging nicely by introducing bpf_log() helper. - rebased. Revolutionize bpf tracing and bpf C programming. C language allows any pointer to be typecasted to any other pointer or convert integer to a pointer. Though bpf verifier is operating at assembly level it has strict type checking for fixed number of types. Known types are defined in 'enum bpf_reg_type'. For example: PTR_TO_FLOW_KEYS is a pointer to 'struct bpf_flow_keys' PTR_TO_SOCKET is a pointer to 'struct bpf_sock', and so on. When it comes to bpf tracing there are no types to track. bpf+kprobe receives 'struct pt_regs' as input. bpf+raw_tracepoint receives raw kernel arguments as an array of u64 values. It was up to bpf program to interpret these integers. Typical tracing program looks like: int bpf_prog(struct pt_regs *ctx) { struct net_device *dev; struct sk_buff *skb; int ifindex; skb = (struct sk_buff *) ctx->di; bpf_probe_read(&dev, sizeof(dev), &skb->dev); bpf_probe_read(&ifindex, sizeof(ifindex), &dev->ifindex); } Addressing mistakes will not be caught by C compiler or by the verifier. The program above could have typecasted ctx->si to skb and page faulted on every bpf_probe_read(). bpf_probe_read() allows reading any address and suppresses page faults. Typical program has hundreds of bpf_probe_read() calls to walk kernel data structures. Not only tracing program would be slow, but there was always a risk that bpf_probe_read() would read mmio region of memory and cause unpredictable hw behavior. With introduction of Compile Once Run Everywhere technology in libbpf and in LLVM and BPF Type Format (BTF) the verifier is finally ready for the next step in program verification. Now it can use in-kernel BTF to type check bpf assembly code. Equivalent program will look like: struct trace_kfree_skb { struct sk_buff *skb; void *location; }; SEC("raw_tracepoint/kfree_skb") int trace_kfree_skb(struct trace_kfree_skb* ctx) { struct sk_buff *skb = ctx->skb; struct net_device *dev; int ifindex; __builtin_preserve_access_index(({ dev = skb->dev; ifindex = dev->ifindex; })); } These patches teach bpf verifier to recognize kfree_skb's first argument as 'struct sk_buff *' because this is what kernel C code is doing. The bpf program cannot 'cheat' and say that the first argument to kfree_skb raw_tracepoint is some other type. The verifier will catch such type mismatch between bpf program assumption of kernel code and the actual type in the kernel. Furthermore skb->dev access is type tracked as well. The verifier can see which field of skb is being read in bpf assembly. It will match offset to type. If bpf program has code: struct net_device *dev = (void *)skb->len; C compiler will not complain and generate bpf assembly code, but the verifier will recognize that integer 'len' field is being accessed at offsetof(struct sk_buff, len) and will reject further dereference of 'dev' variable because it contains integer value instead of a pointer. Such sophisticated type tracking allows calling networking bpf helpers from tracing programs. This patchset allows calling bpf_skb_event_output() that dumps skb data into perf ring buffer. It greatly improves observability. Now users can not only see packet lenth of the skb about to be freed in kfree_skb() kernel function, but can dump it to user space via perf ring buffer using bpf helper that was previously available only to TC and socket filters. See patch 10 for full example. The end result is safer and faster bpf tracing. Safer - because type safe direct load can be used most of the time instead of bpf_probe_read(). Faster - because direct loads are used to walk kernel data structures instead of bpf_probe_read() calls. Note that such loads can page fault and are supported by hidden bpf_probe_read() in interpreter and via exception table if program is JITed. ==================== Signed-off-by: -
Alexei Starovoitov authored
Load basic cls_bpf program. Load raw_tracepoint program and attach to kfree_skb raw tracepoint. Trigger cls_bpf via prog_test_run. At the end of test_run kernel will call kfree_skb which will trigger trace_kfree_skb tracepoint. Which will call our raw_tracepoint program. Which will take that skb and will dump it into perf ring buffer. Check that user space received correct packet. Signed-off-by:
-
Alexei Starovoitov authored
Introduce new helper that reuses existing skb perf_event output implementation, but can be called from raw_tracepoint programs that receive 'struct sk_buff *' as tracepoint argument or can walk other kernel data structures to skb pointer. In order to do that teach verifier to resolve true C types of bpf helpers into in-kernel BTF ids. The type of kernel pointer passed by raw tracepoint into bpf program will be tracked by the verifier all the way until it's passed into helper function. For example: kfree_skb() kernel function calls trace_kfree_skb(skb, loc); bpf programs receives that skb pointer and may eventually pass it into bpf_skb_output() bpf helper which in-kernel is implemented via bpf_skb_event_output() kernel function. Its first argument in the kernel is 'struct sk_buff *'. The verifier makes sure that types match all the way. Signed-off-by:
-
Alexei Starovoitov authored
Pointer to BTF object is a pointer to kernel object or NULL. Such pointers can only be used by BPF_LDX instructions. The verifier changed their opcode from LDX|MEM|size to LDX|PROBE_MEM|size to make JITing easier. The number of entries in extable is the number of BPF_LDX insns that access kernel memory via "pointer to BTF type". Only these load instructions can fault. Since x86 extable is relative it has to be allocated in the same memory region as JITed code. Allocate it prior to last pass of JITing and let the last pass populate it. Pointer to extable in bpf_prog_aux is necessary to make page fault handling fast. Page fault handling is done in two steps: 1. bpf_prog_kallsyms_find() finds BPF program that page faulted. It's done by walking rb tree. 2. then extable for given bpf program is binary searched. This process is similar to how page faulting is done for kernel modules. The exception handler skips over faulting x86 instruction and initializes destination register with zero. This mimics exact behavior of bpf_probe_read (when probe_kernel_read faults dest is zeroed). JITs for other architectures can add support in similar way. Until then they will reject unknown opcode and fallback to interpreter. Since extable should be aligned and placed near JITed code make bpf_jit_binary_alloc() return 4 byte aligned image offset, so that extable aligning formula in bpf_int_jit_compile() doesn't need to rely on internal implementation of bpf_jit_binary_alloc(). On x86 gcc defaults to 16-byte alignment for regular kernel functions due to better performance. JITed code may be aligned to 16 in the future, but it will use 4 in the meantime. Signed-off-by:
-
Alexei Starovoitov authored
Pointer to BTF object is a pointer to kernel object or NULL. The memory access in the interpreter has to be done via probe_kernel_read to avoid page faults. Signed-off-by:
-
Alexei Starovoitov authored
BTF type id specified at program load time has all necessary information to attach that program to raw tracepoint. Use kernel type name to find raw tracepoint. Add missing CHECK_ATTR() condition. Signed-off-by:
-
Alexei Starovoitov authored
libbpf analyzes bpf C program, searches in-kernel BTF for given type name and stores it into expected_attach_type. The kernel verifier expects this btf_id to point to something like: typedef void (*btf_trace_kfree_skb)(void *, struct sk_buff *skb, void *loc); which represents signature of raw_tracepoint "kfree_skb". Then btf_ctx_access() matches ctx+0 access in bpf program with 'skb' and 'ctx+8' access with 'loc' arguments of "kfree_skb" tracepoint. In first case it passes btf_id of 'struct sk_buff *' back to the verifier core and 'void *' in second case. Then the verifier tracks PTR_TO_BTF_ID as any other pointer type. Like PTR_TO_SOCKET points to 'struct bpf_sock', PTR_TO_TCP_SOCK points to 'struct bpf_tcp_sock', and so on. PTR_TO_BTF_ID points to in-kernel structs. If 1234 is btf_id of 'struct sk_buff' in vmlinux's BTF then PTR_TO_BTF_ID#1234 points to one of in kernel skbs. When PTR_TO_BTF_ID#1234 is dereferenced (like r2 = *(u64 *)r1 + 32) the btf_struct_access() checks which field of 'struct sk_buff' is at offset 32. Checks that size of access matches type definition of the field and continues to track the dereferenced type. If that field was a pointer to 'struct net_device' the r2's type will be PTR_TO_BTF_ID#456. Where 456 is btf_id of 'struct net_device' in vmlinux's BTF. Such verifier analysis prevents "cheating" in BPF C program. The program cannot cast arbitrary pointer to 'struct sk_buff *' and access it. C compiler would allow type cast, of course, but the verifier will notice type mismatch based on BPF assembly and in-kernel BTF. Signed-off-by:
-
Alexei Starovoitov authored
It's a responsiblity of bpf program author to annotate the program with SEC("tp_btf/name") where "name" is a valid raw tracepoint. The libbpf will try to find "name" in vmlinux BTF and error out in case vmlinux BTF is not available or "name" is not found. If "name" is indeed a valid raw tracepoint then in-kernel BTF will have "btf_trace_##name" typedef that points to function prototype of that raw tracepoint. BTF description captures exact argument the kernel C code is passing into raw tracepoint. The kernel verifier will check the types while loading bpf program. libbpf keeps BTF type id in expected_attach_type, but since kernel ignores this attribute for tracing programs copy it into attach_btf_id attribute before loading. Later the kernel will use prog->attach_btf_id to select raw tracepoint during bpf_raw_tracepoint_open syscall command. Signed-off-by: -
Alexei Starovoitov authored
Add attach_btf_id attribute to prog_load command. It's similar to existing expected_attach_type attribute which is used in several cgroup based program types. Unfortunately expected_attach_type is ignored for tracing programs and cannot be reused for new purpose. Hence introduce attach_btf_id to verify bpf programs against given in-kernel BTF type id at load time. It is strictly checked to be valid for raw_tp programs only. In a later patches it will become: btf_id == 0 semantics of existing raw_tp progs. btd_id > 0 raw_tp with BTF and additional type safety. Signed-off-by:
-
Alexei Starovoitov authored
If in-kernel BTF exists parse it and prepare 'struct btf *btf_vmlinux' for further use by the verifier. In-kernel BTF is trusted just like kallsyms and other build artifacts embedded into vmlinux. Yet run this BTF image through BTF verifier to make sure that it is valid and it wasn't mangled during the build. If in-kernel BTF is incorrect it means either gcc or pahole or kernel are buggy. In such case disallow loading BPF programs. Signed-off-by:
-
Alexei Starovoitov authored
When pahole converts dwarf to btf it emits only used types. Wrap existing bpf helper functions into typedef and use it in typecast to make gcc emits this type into dwarf. Then pahole will convert it to btf. The "btf_#name_of_helper" types will be used to figure out types of arguments of bpf helpers. The generated code before and after is the same. Only dwarf and btf sections are different. Signed-off-by:
-
Alexei Starovoitov authored
When pahole converts dwarf to btf it emits only used types. Wrap existing __bpf_trace_##template() function into btf_trace_##template typedef and use it in type cast to make gcc emits this type into dwarf. Then pahole will convert it to btf. The "btf_trace_" prefix will be used to identify BTF enabled raw tracepoints. Signed-off-by:
-
- 16 Oct, 2019 2 commits
-
-
Song Liu authored
bpf stackmap with build-id lookup (BPF_F_STACK_BUILD_ID) can trigger A-A deadlock on rq_lock(): rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [...] Call Trace: try_to_wake_up+0x1ad/0x590 wake_up_q+0x54/0x80 rwsem_wake+0x8a/0xb0 bpf_get_stack+0x13c/0x150 bpf_prog_fbdaf42eded9fe46_on_event+0x5e3/0x1000 bpf_overflow_handler+0x60/0x100 __perf_event_overflow+0x4f/0xf0 perf_swevent_overflow+0x99/0xc0 ___perf_sw_event+0xe7/0x120 __schedule+0x47d/0x620 schedule+0x29/0x90 futex_wait_queue_me+0xb9/0x110 futex_wait+0x139/0x230 do_futex+0x2ac/0xa50 __x64_sys_futex+0x13c/0x180 do_syscall_64+0x42/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This can be reproduced by: 1. Start a multi-thread program that does parallel mmap() and malloc(); 2. taskset the program to 2 CPUs; 3. Attach bpf program to trace_sched_switch and gather stackmap with build-id, e.g. with trace.py from bcc tools: trace.py -U -p <pid> -s <some-bin,some-lib> t:sched:sched_switch A sample reproducer is attached at the end. This could also trigger deadlock with other locks that are nested with rq_lock. Fix this by checking whether irqs are disabled. Since rq_lock and all other nested locks are irq safe, it is safe to do up_read() when irqs are not disable. If the irqs are disabled, postpone up_read() in irq_work. Fixes: 615755a7 ("bpf: extend stackmap to save binary_build_id+offset instead of address") Signed-off-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
-
Jakub Sitnicki authored
Make the compiler report a clear error when bpf_helpers_doc.py needs updating rather than rely on the fact that Clang fails to compile English: ../../../lib/bpf/bpf_helper_defs.h:2707:1: error: unknown type name 'Unrecognized' Unrecognized type 'struct bpf_inet_lookup', please add it to known types! Signed-off-by:
-
- 15 Oct, 2019 7 commits
-
-
Jiri Pirko authored
Recently couple of files that are write only were added to netdevsim debugfs. Don't read these files and avoid error. Reported-by:
kernel test robot <rong.a.chen@intel.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com>
-
Stanislav Fomichev authored
Make sure BPF_PROG_TEST_RUN accepts tstamp and exports any modifications that BPF program does. Signed-off-by:
Stanislav Fomichev <sdf@google.com> Signed-off-by:
-
Stanislav Fomichev authored
It's useful for implementing EDT related tests (set tstamp, run the test, see how the tstamp is changed or observe some other parameter). Note that bpf_ktime_get_ns() helper is using monotonic clock, so for the BPF programs that compare tstamp against it, tstamp should be derived from clock_gettime(CLOCK_MONOTONIC, ...). Signed-off-by:
-
Alexei Starovoitov authored
Andrii Nakryiko says: ==================== This patch set generalizes libbpf's CO-RE relocation support. In addition to existing field's byte offset relocation, libbpf now supports field existence relocations, which are emitted by Clang when using __builtin_preserve_field_info(<field>, BPF_FIELD_EXISTS). A convenience bpf_core_field_exists() macro is added to bpf_core_read.h BPF-side header, along the bpf_field_info_kind enum containing currently supported types of field information libbpf supports. This list will grow as libbpf gains support for other relo kinds. This patch set upgrades the format of .BTF.ext's relocation record to match latest Clang's format (12 -> 16 bytes). This is not a breaking change, as the previous format hasn't been released yet as part of official Clang version release. v1->v2: - unify bpf_field_info_kind enum and naming changes (Alexei); - added bpf_core_field_exists() to bpf_core_read.h. ==================== Signed-off-by: -
Andrii Nakryiko authored
Add a bunch of tests validating CO-RE is handling field existence relocation. Relaxed CO-RE relocation mode is activated for these new tests to prevent libbpf from rejecting BPF object for no-match relocation, even though test BPF program is not going to use that relocation, if field is missing. Signed-off-by:
-
Andrii Nakryiko authored
Add enum definition for Clang's __builtin_preserve_field_info() second argument (info_kind). Currently only byte offset and existence are supported. Corresponding Clang changes introducing this built-in can be found at [0] [0] https://reviews.llvm.org/D67980Signed-off-by:
-
Andrii Nakryiko authored
Add support for BPF_FRK_EXISTS relocation kind to detect existence of captured field in a destination BTF, allowing conditional logic to handle incompatible differences between kernels. Also introduce opt-in relaxed CO-RE relocation handling option, which makes libbpf emit warning for failed relocations, but proceed with other relocations. Instruction, for which relocation failed, is patched with (u32)-1 value. Signed-off-by:
-
