- 22 Oct, 2021 14 commits
-
-
Mauricio Vásquez authored
Free btf_dedup if btf_ensure_modifiable() returns error. Fixes: 919d2b1d ("libbpf: Allow modification of BTF and add btf__add_str API") Signed-off-by:
Mauricio Vásquez <mauricio@kinvolk.io> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211022202035.48868-1-mauricio@kinvolk.io
-
Andrii Nakryiko authored
Recent change to use tp/syscalls/sys_enter_nanosleep for perf_buffer selftests causes this selftest to fail on 4.9 kernel in libbpf CI ([0]): libbpf: prog 'handle_sys_enter': failed to attach to perf_event FD 6: Invalid argument libbpf: prog 'handle_sys_enter': failed to attach to tracepoint 'syscalls/sys_enter_nanosleep': Invalid argument It's not exactly clear why, because perf_event itself is created for this tracepoint, but I can't even compile 4.9 kernel locally, so it's hard to figure this out. If anyone has better luck and would like to help investigating this, I'd really appreciate this. For now, unblock CI by switching back to raw_syscalls/sys_enter, but reduce amount of unnecessary samples emitted by filter by process ID. Use explicit ARRAY map for that to make it work on 4.9 as well, because global data isn't yet supported there. Fixes: aa274f98 ("selftests/bpf: Fix possible/online index mismatch in perf_buffer test") Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211022201342.3490692-1-andrii@kernel.org
-
Andrii Nakryiko authored
Building libbpf sources out of kernel tree (in Github repo) we run into compilation error due to unknown __aligned attribute. It must be coming from some kernel header, which is not available to Github sources. Use explicit __attribute__((aligned(16))) instead. Fixes: 961632d5 ("libbpf: Fix dumping non-aligned __int128") Signed-off-by:
-
Alexei Starovoitov authored
Andrii Nakryiko says: ==================== This patch set refactors internals of libbpf to enable support for multiple custom .rodata.* and .data.* sections. Each such section is backed by its own BPF_MAP_TYPE_ARRAY, memory-mappable just like .rodata/.data. This is not extended to .bss because .bss is not a great name, it is generated by compiler with name that reflects completely irrelevant historical implementation details. Given that users have to annotate their variables with SEC(".data.my_sec") explicitly, standardizing on .rodata. and .data. prefixes makes more sense and keeps things simpler. Additionally, this patch set makes it simpler to work with those special internal maps by allowing to look them up by their full ELF section name. Patch #1 is a preparatory patch that deprecates one libbpf API and moves custom logic into libbpf.c, where it's used. This code is later refactored with the rest of libbpf.c logic to support multiple data section maps. See individual patches for all the details. For new custom "dot maps", their full ELF section names are used as the names that are sent into the kernel. Object name isn't prepended like for .data/.rodata/.bss. The reason is that with longer custom names, there isn't much space left for object name anyways. Also, if BTF is supported, btf_value_type_id points to DATASEC BTF type, which contains full original ELF name of the section, so tools like bpftool could use that to recover full name. This patch set doesn't add this logic yet, this is left for follow up patches. One interesting possibility that is now open by these changes is that it's possible to do: bpf_trace_printk("My fmt %s", sizeof("My fmt %s"), "blah"); and it will work as expected. I haven't updated libbpf-provided helpers in bpf_helpers.h for snprintf, seq_printf, and printk, because using `static const char ___fmt[] = fmt;` trick is still efficient and doesn't fill out the buffer at runtime (no copying). But we might consider updating them in the future, especially with the array check that Kumar proposed (see [0]). [0] https://lore.kernel.org/bpf/20211012041524.udytbr2xs5wid6x2@apollo.localdomain/ v1->v2: - don't prepend object name for new dot maps; - add __read_mostly example in selftests (Daniel). ==================== Signed-off-by: -
Andrii Nakryiko authored
Utilize libbpf's feature of allowing to lookup internal maps by their ELF section names. No need to guess or calculate the exact truncated prefix taken from the object name. Signed-off-by:
Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20211021014404.2635234-11-andrii@kernel.org
-
Andrii Nakryiko authored
Map name that's assigned to internal maps (.rodata, .data, .bss, etc) consist of a small prefix of bpf_object's name and ELF section name as a suffix. This makes it hard for users to "guess" the name to use for looking up by name with bpf_object__find_map_by_name() API. One proposal was to drop object name prefix from the map name and just use ".rodata", ".data", etc, names. One downside called out was that when multiple BPF applications are active on the host, it will be hard to distinguish between multiple instances of .rodata and know which BPF object (app) they belong to. Having few first characters, while quite limiting, still can give a bit of a clue, in general. Note, though, that btf_value_type_id for such global data maps (ARRAY) points to DATASEC type, which encodes full ELF name, so tools like bpftool can take advantage of this fact to "recover" full original name of the map. This is also the reason why for custom .data.* and .rodata.* maps libbpf uses only their ELF names and doesn't prepend object name at all. Another downside of such approach is that it is not backwards compatible and, among direct use of bpf_object__find_map_by_name() API, will break any BPF skeleton generated using bpftool that was compiled with older libbpf version. Instead of causing all this pain, libbpf will still generate map name using a combination of object name and ELF section name, but it will allow looking such maps up by their natural names, which correspond to their respective ELF section names. This means non-truncated ELF section names longer than 15 characters are going to be expected and supported. With such set up, we get the best of both worlds: leave small bits of a clue about BPF application that instantiated such maps, as well as making it easy for user apps to lookup such maps at runtime. In this sense it closes corresponding libbpf 1.0 issue ([0]). BPF skeletons will continue using full names for lookups. [0] Closes: https://github.com/libbpf/libbpf/issues/275Signed-off-by:
-
Andrii Nakryiko authored
Enhance existing selftests to demonstrate the use of custom .data/.rodata sections. Signed-off-by:
-
Andrii Nakryiko authored
Add support for having multiple .rodata and .data data sections ([0]). .rodata/.data are supported like the usual, but now also .rodata.<whatever> and .data.<whatever> are also supported. Each such section will get its own backing BPF_MAP_TYPE_ARRAY, just like .rodata and .data. Multiple .bss maps are not supported, as the whole '.bss' name is confusing and might be deprecated soon, as well as user would need to specify custom ELF section with SEC() attribute anyway, so might as well stick to just .data.* and .rodata.* convention. User-visible map name for such new maps is going to be just their ELF section names. [0] https://github.com/libbpf/libbpf/issues/274Signed-off-by:
-
Andrii Nakryiko authored
It can happen that some data sections (e.g., .rodata.cst16, containing compiler populated string constants) won't have a corresponding BTF DATASEC type. Now that libbpf supports .rodata.* and .data.* sections, situation like that will cause invalid BPF skeleton to be generated that won't compile successfully, as some parts of skeleton would assume memory-mapped struct definitions for each special data section. Fix this by generating empty struct definitions for such data sections. Signed-off-by:
-
Andrii Nakryiko authored
Remove the assumption about only single instance of each of .rodata and .data internal maps. Nothing changes for '.rodata' and '.data' maps, but new '.rodata.something' map will get 'rodata_something' section in BPF skeleton for them (as well as having struct bpf_map * field in maps section with the same field name). Signed-off-by:
-
Andrii Nakryiko authored
Remove internal libbpf assumption that there can be only one .rodata, .data, and .bss map per BPF object. To achieve that, extend and generalize the scheme that was used for keeping track of relocation ELF sections. Now each ELF section has a temporary extra index that keeps track of logical type of ELF section (relocations, data, read-only data, BSS). Switch relocation to this scheme, as well as .rodata/.data/.bss handling. We don't yet allow multiple .rodata, .data, and .bss sections, but no libbpf internal code makes an assumption that there can be only one of each and thus they can be explicitly referenced by a single index. Next patches will actually allow multiple .rodata and .data sections. Signed-off-by:
-
Andrii Nakryiko authored
Minimize the usage of class-agnostic gelf_xxx() APIs from libelf. These APIs require copying ELF data structures into local GElf_xxx structs and have a more cumbersome API. BPF ELF file is defined to be always 64-bit ELF object, even when intended to be run on 32-bit host architectures, so there is no need to do class-agnostic conversions everywhere. BPF static linker implementation within libbpf has been using Elf64-specific types since initial implementation. Add two simple helpers, elf_sym_by_idx() and elf_rel_by_idx(), for more succinct direct access to ELF symbol and relocation records within ELF data itself and switch all the GElf_xxx usage into Elf64_xxx equivalents. The only remaining place within libbpf.c that's still using gelf API is gelf_getclass(), as there doesn't seem to be a direct way to get underlying ELF bitness. No functional changes intended. Signed-off-by:
-
Andrii Nakryiko authored
Name currently anonymous internal struct that keeps ELF-related state for bpf_object. Just a bit of clean up, no functional changes. Signed-off-by:
-
Andrii Nakryiko authored
There isn't a good use case where anyone but libbpf itself needs to call btf__finalize_data(). It was implemented for internal use and it's not clear why it was made into public API in the first place. To function, it requires active ELF data, which is stored inside bpf_object for the duration of opening phase only. But the only BTF that needs bpf_object's ELF is that bpf_object's BTF itself, which libbpf fixes up automatically during bpf_object__open() operation anyways. There is no need for any additional fix up and no reasonable scenario where it's useful and appropriate. Thus, btf__finalize_data() is just an API atavism and is better removed. So this patch marks it as deprecated immediately (v0.6+) and moves the code from btf.c into libbpf.c where it's used in the context of bpf_object opening phase. Such code co-location allows to make code structure more straightforward and remove bpf_object__section_size() and bpf_object__variable_offset() internal helpers from libbpf_internal.h, making them static. Their naming is also adjusted to not create a wrong illusion that they are some sort of method of bpf_object. They are internal helpers and are called appropriately. This is part of libbpf 1.0 effort ([0]). [0] Closes: https://github.com/libbpf/libbpf/issues/276Signed-off-by:
-
- 21 Oct, 2021 14 commits
-
-
Andrii Nakryiko authored
Jiri Olsa says: ==================== hi, sending fixes for perf_buffer test on systems with offline cpus. v2: - resend due to delivery issues, no changes thanks, jirka Acked-by:
John Fastabend <john.fastabend@gmail.com> ==================== Signed-off-by:
-
Jiri Olsa authored
The perf buffer tests triggers trace with nanosleep syscall, but monitors all syscalls, which results in lot of data in the buffer and makes it harder to debug. Let's lower the trace traffic and monitor just nanosleep syscall. Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
-
Jiri Olsa authored
The perf_buffer fails on system with offline cpus: # test_progs -t perf_buffer serial_test_perf_buffer:PASS:nr_cpus 0 nsec serial_test_perf_buffer:PASS:nr_on_cpus 0 nsec serial_test_perf_buffer:PASS:skel_load 0 nsec serial_test_perf_buffer:PASS:attach_kprobe 0 nsec serial_test_perf_buffer:PASS:perf_buf__new 0 nsec serial_test_perf_buffer:PASS:epoll_fd 0 nsec skipping offline CPU #4 serial_test_perf_buffer:PASS:perf_buffer__poll 0 nsec serial_test_perf_buffer:PASS:seen_cpu_cnt 0 nsec serial_test_perf_buffer:PASS:buf_cnt 0 nsec ... serial_test_perf_buffer:PASS:fd_check 0 nsec serial_test_perf_buffer:PASS:drain_buf 0 nsec serial_test_perf_buffer:PASS:consume_buf 0 nsec serial_test_perf_buffer:FAIL:cpu_seen cpu 5 not seen #88 perf_buffer:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED If the offline cpu is from the middle of the possible set, we get mismatch with possible and online cpu buffers. The perf buffer test calls perf_buffer__consume_buffer for all 'possible' cpus, but the library holds only 'online' cpu buffers and perf_buffer__consume_buffer returns them based on index. Adding extra (online) index to keep track of online buffers, we need the original (possible) index to trigger trace on proper cpu. Signed-off-by:
-
Jiri Olsa authored
The perf_buffer fails on system with offline cpus: # test_progs -t perf_buffer test_perf_buffer:PASS:nr_cpus 0 nsec test_perf_buffer:PASS:nr_on_cpus 0 nsec test_perf_buffer:PASS:skel_load 0 nsec test_perf_buffer:PASS:attach_kprobe 0 nsec test_perf_buffer:PASS:perf_buf__new 0 nsec test_perf_buffer:PASS:epoll_fd 0 nsec skipping offline CPU #24 skipping offline CPU #25 skipping offline CPU #26 skipping offline CPU #27 skipping offline CPU #28 skipping offline CPU #29 skipping offline CPU #30 skipping offline CPU #31 test_perf_buffer:PASS:perf_buffer__poll 0 nsec test_perf_buffer:PASS:seen_cpu_cnt 0 nsec test_perf_buffer:FAIL:buf_cnt got 24, expected 32 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Changing the test to check online cpus instead of possible. Signed-off-by:
-
Andrii Nakryiko authored
Dave Marchevsky says: ==================== This is a followup to discussion around RFC patchset "bpf: keep track of prog verification stats" [0]. The RFC elaborates on my usecase, but to summarize: keeping track of verifier stats for programs as they - and the kernels they run on - change over time can help developers of individual programs and BPF kernel folks. The RFC added a verif_stats to the uapi which contained most of the info which verifier prints currently. Feedback here was to avoid polluting uapi with stats that might be meaningless after major changes to the verifier, but that insn_processed or conceptually similar number would exist in the long term and was safe to expose. So let's expose just insn_processed via bpf_prog_info and fdinfo for now and explore good ways of getting more complicated stats in the future. [0] https://lore.kernel.org/bpf/20210920151112.3770991-1-davemarchevsky@fb.com/ v2->v3: * Remove unnecessary check in patch 2's test [Andrii] * Go back to adding new u32 in bpf_prog_info (vs using spare bits) [Andrii] * Rebase + add acks [Andrii, John] v1->v2: * Rename uapi field from insn_processed to verified_insns [Daniel] * use 31 bits of existing bitfield space in bpf_prog_info [Daniel] * change underlying type from 64-> 32 bits [Daniel] ==================== Signed-off-by:
-
Dave Marchevsky authored
verified_insns field was added to response of bpf_obj_get_info_by_fd call on a prog. Confirm that it's being populated by loading a simple program and asking for its info. Signed-off-by:
Dave Marchevsky <davemarchevsky@fb.com> Signed-off-by:
-
Dave Marchevsky authored
This stat is currently printed in the verifier log and not stored anywhere. To ease consumption of this data, add a field to bpf_prog_aux so it can be exposed via BPF_OBJ_GET_INFO_BY_FD and fdinfo. Signed-off-by:
-
Ilya Leoshkevich authored
Currently ptr_is_aligned() takes size, and not alignment, as a parameter, which may be overly pessimistic e.g. for __i128 on s390, which must be only 8-byte aligned. Fix by using btf__align_of(). Signed-off-by:
Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by:
-
Alexei Starovoitov authored
Hengqi Chen says: ==================== This patch set adds a new BPF helper bpf_skc_to_unix_sock(). The helper is used in tracing programs to cast a socket pointer to a unix_sock pointer. v2->v3: - Use abstract socket in selftest (Alexei) - Run checkpatch script over patches (Andrii) v1->v2: - Update selftest, remove trailing spaces changes (Song) ==================== Signed-off-by: -
Hengqi Chen authored
Add a new test which triggers unix_listen kernel function to test bpf_skc_to_unix_sock helper. Signed-off-by:
Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by:
-
Hengqi Chen authored
The helper is used in tracing programs to cast a socket pointer to a unix_sock pointer. The return value could be NULL if the casting is illegal. Suggested-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
-
Pu Lehui authored
When compiling bpf samples, the following warning appears: readelf: Error: Missing knowledge of 32-bit reloc types used in DWARF sections of machine number 247 readelf: Warning: unable to apply unsupported reloc type 10 to section .debug_info readelf: Warning: unable to apply unsupported reloc type 1 to section .debug_info readelf: Warning: unable to apply unsupported reloc type 10 to section .debug_info Same problem was mentioned in commit 2f092126 ("selftests/bpf: suppress readelf stderr when probing for BTF support"), let's use readelf that supports btf. Signed-off-by:
Pu Lehui <pulehui@huawei.com> Signed-off-by:
-
Qing Wang authored
This patch fixes the following Coccinelle warning: net/bpf/test_run.c:361:8-15: WARNING opportunity for memdup_user net/bpf/test_run.c:1055:8-15: WARNING opportunity for memdup_user Use memdup_user rather than duplicating its implementation This is a little bit restricted to reduce false positives Signed-off-by:
Qing Wang <wangqing@vivo.com> Signed-off-by:
-
Brendan Jackman authored
Some new verifier tests that hit some important gaps in the parameter space for atomic ops. There are already exhaustive tests for the JIT part in lib/test_bpf.c, but these exercise the verifier too. Signed-off-by:
Brendan Jackman <jackmanb@google.com> Signed-off-by:
-
- 20 Oct, 2021 9 commits
-
-
Andrii Nakryiko authored
Ilya Leoshkevich says: ==================== This series along with [1] and [2] fixes all the failures in the btf_dump testsuite currently present on s390, in particular: * [1] fixes intermittent build bug causing "failed to encode tag ..." * error messages. * [2] fixes missing VAR entries on s390. * Patch 1 disables Intel-specific code in a testcase. * Patch 2 fixes an endianness-related bug. * Patch 3 fixes an alignment-related bug. * Patch 4 improves overly pessimistic alignment handling. [1] https://lore.kernel.org/bpf/20211012022521.399302-1-iii@linux.ibm.com/ [2] https://lore.kernel.org/bpf/20211012022637.399365-1-iii@linux.ibm.com/ v1: https://lore.kernel.org/bpf/20211012023218.399568-1-iii@linux.ibm.com/ v1 -> v2: - Remove redundant local variables, use t->size directly instead. Best regards, Ilya ==================== Signed-off-by:
-
Ilya Leoshkevich authored
Non-aligned integers are dumped as bitfields, which is supported for at most 64-bit integers. Fix by using the same trick as btf_dump_float_data(): copy non-aligned values to the local buffer. Signed-off-by:
-
Ilya Leoshkevich authored
On big-endian arches not only bytes, but also bits are numbered in reverse order (see e.g. S/390 ELF ABI Supplement, but this is also true for other big-endian arches as well). Signed-off-by:
-
Ilya Leoshkevich authored
cpu_number exists only on Intel and aarch64, so skip the test involing it on other arches. An alternative would be to replace it with an exported non-ifdefed primitive-typed percpu variable from the common code, but there appears to be none. Signed-off-by:
-
David Yang authored
The coccinelle check report: "./samples/bpf/xdp_redirect_cpu_user.c:397:32-38: ERROR: application of sizeof to pointer" Using the "strlen" to fix it. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
David Yang <davidcomponentone@gmail.com> Signed-off-by:
-
Quentin Monnet authored
The header is no longer needed since the event_pipe implementation was updated to rely on libbpf's perf_buffer. This makes bpftool free of dependencies to perf files, and we can update the Makefile accordingly. Fixes: 9b190f18 ("tools/bpftool: switch map event_pipe to libbpf's perf_buffer") Signed-off-by:
Quentin Monnet <quentin@isovalent.com> Signed-off-by:
-
Wan Jiabing authored
Fix following checkincludes.pl warning: ./scripts/checkincludes.pl tools/testing/selftests/bpf/cgroup_helpers.c tools/testing/selftests/bpf/cgroup_helpers.c: unistd.h is included more than once. Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
-
Quentin Monnet authored
kernel/bpf/preload/Makefile was recently updated to have it install libbpf's headers locally instead of pulling them from tools/lib/bpf. But two items still need to be addressed. First, the local .gitignore file was not adjusted to ignore the files generated in the new kernel/bpf/preload/libbpf output directory. Second, the "clean-files" target is now incorrect. The old artefacts names were not removed from the target, while the new ones were added incorrectly. This is because "clean-files" expects names relative to $(obj), but we passed the absolute path instead. This results in the output and header-destination directories for libbpf (and their contents) not being removed from kernel/bpf/preload on "make clean" from the root of the repository. This commit fixes both issues. Note that $(userprogs) needs not be added to "clean-files", because the cleaning infrastructure already accounts for it. Cleaning the files properly also prevents make from printing the following message, for builds coming after a "make clean": "make[4]: Nothing to be done for 'install_headers'." v2: Simplify the "clean-files" target. Fixes: bf607917 ("bpf: preload: Install libbpf headers when building") Signed-off-by:
-
Dave Marchevsky authored
In preparation for bpf_program__get_prog_info_linear deprecation, move the single use in libbpf to call bpf_obj_get_info_by_fd directly. Signed-off-by:
-
- 19 Oct, 2021 3 commits
-
-
Kumar Kartikeya Dwivedi authored
The helper function returns a pointer that in the failure case encodes an error in the struct btf pointer. The current code lead to Coverity warning about the use of the invalid pointer: *** CID 1507963: Memory - illegal accesses (USE_AFTER_FREE) /kernel/bpf/verifier.c: 1788 in find_kfunc_desc_btf() 1782 return ERR_PTR(-EINVAL); 1783 } 1784 1785 kfunc_btf = __find_kfunc_desc_btf(env, offset, btf_modp); 1786 if (IS_ERR_OR_NULL(kfunc_btf)) { 1787 verbose(env, "cannot find module BTF for func_id %u\n", func_id); >>> CID 1507963: Memory - illegal accesses (USE_AFTER_FREE) >>> Using freed pointer "kfunc_btf". 1788 return kfunc_btf ?: ERR_PTR(-ENOENT); 1789 } 1790 return kfunc_btf; 1791 } 1792 return btf_vmlinux ?: ERR_PTR(-ENOENT); 1793 } Daniel suggested the use of ERR_CAST so that the intended use is clear to Coverity, but on closer look it seems that we never return NULL from the helper. Andrii noted that since __find_kfunc_desc_btf already logs errors for all cases except btf_get_by_fd, it is much easier to add logging for that and remove the IS_ERR check altogether, returning directly from it. Suggested-by:Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by:
-
Andrii Nakryiko authored
Quentin Monnet says: ==================== This set contains one fix for bpftool's Makefile, to make sure that the headers internal to libbpf are installed properly even if we add more headers to the relevant Makefile variable in the future (although we'd like to avoid that if possible). The other patches aim at cleaning up the output from the Makefile, in particular when running the command "make" another time after bpftool is built. ==================== Signed-off-by: -
Quentin Monnet authored
One of bpftool's object files depends on zlib. To make sure we do not attempt to build that object when the library is not available, commit d66fa3c7 ("tools: bpftool: add feature check for zlib") introduced a feature check to detect whether zlib is present. This check comes as a rule for which the target ("zdep") is a nonexistent file (phony target), which means that the Makefile always attempts to rebuild it. It is mostly harmless. However, one side effect is that, on running again once bpftool is already built, make considers that "something" (the recipe for zdep) was executed, and does not print the usual message "make: Nothing to be done for 'all'", which is a user-friendly indicator that the build went fine. Before, with some level of debugging information: $ make --debug=m [...] Reading makefiles... Auto-detecting system features: ... libbfd: [ on ] ... disassembler-four-args: [ on ] ... zlib: [ on ] ... libcap: [ on ] ... clang-bpf-co-re: [ on ] Updating makefiles.... Updating goal targets.... File 'all' does not exist. File 'zdep' does not exist. Must remake target 'zdep'. File 'all' does not exist. Must remake target 'all'. Successfully remade target file 'all'. After the patch: $ make --debug=m [...] Auto-detecting system features: ... libbfd: [ on ] ... disassembler-four-args: [ on ] ... zlib: [ on ] ... libcap: [ on ] ... clang-bpf-co-re: [ on ] Updating makefiles.... Updating goal targets.... File 'all' does not exist. Must remake target 'all'. Successfully remade target file 'all'. make: Nothing to be done for 'all'. (Note the last line, which is not part of make's debug information.) Signed-off-by:
-
