- 22 10月, 2021 10 次提交
-
-
由 Andrii Nakryiko 提交于
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: NAndrii Nakryiko <andrii@kernel.org> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NSong Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20211021014404.2635234-3-andrii@kernel.org
-
由 Andrii Nakryiko 提交于
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: NAndrii Nakryiko <andrii@kernel.org> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NSong Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20211021014404.2635234-2-andrii@kernel.org
-
由 Jiri Olsa 提交于
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: NJiri Olsa <jolsa@kernel.org> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211021114132.8196-4-jolsa@kernel.org
-
由 Jiri Olsa 提交于
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: NJiri Olsa <jolsa@kernel.org> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211021114132.8196-3-jolsa@kernel.org
-
由 Jiri Olsa 提交于
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: NJiri Olsa <jolsa@kernel.org> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211021114132.8196-2-jolsa@kernel.org
-
由 Dave Marchevsky 提交于
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: NDave Marchevsky <davemarchevsky@fb.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Acked-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211020074818.1017682-3-davemarchevsky@fb.com
-
由 Dave Marchevsky 提交于
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: NDave Marchevsky <davemarchevsky@fb.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211020074818.1017682-2-davemarchevsky@fb.com
-
由 Ilya Leoshkevich 提交于
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: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211021104658.624944-2-iii@linux.ibm.com
-
由 Hengqi Chen 提交于
Add a new test which triggers unix_listen kernel function to test bpf_skc_to_unix_sock helper. Signed-off-by: NHengqi Chen <hengqi.chen@gmail.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211021134752.1223426-3-hengqi.chen@gmail.com
-
由 Hengqi Chen 提交于
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: NYonghong Song <yhs@fb.com> Signed-off-by: NHengqi Chen <hengqi.chen@gmail.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NSong Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20211021134752.1223426-2-hengqi.chen@gmail.com
-
- 21 10月, 2021 7 次提交
-
-
由 Brendan Jackman 提交于
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: NBrendan Jackman <jackmanb@google.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211015093318.1273686-1-jackmanb@google.com
-
由 Ilya Leoshkevich 提交于
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: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211013160902.428340-4-iii@linux.ibm.com
-
由 Ilya Leoshkevich 提交于
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: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211013160902.428340-3-iii@linux.ibm.com
-
由 Ilya Leoshkevich 提交于
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: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211013160902.428340-2-iii@linux.ibm.com
-
由 Quentin Monnet 提交于
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: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211020094826.16046-1-quentin@isovalent.com
-
由 Wan Jiabing 提交于
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: NWan Jiabing <wanjiabing@vivo.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211012023231.19911-1-wanjiabing@vivo.com
-
由 Dave Marchevsky 提交于
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: NDave Marchevsky <davemarchevsky@fb.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211011082031.4148337-2-davemarchevsky@fb.com
-
- 20 10月, 2021 4 次提交
-
-
由 Quentin Monnet 提交于
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: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211009210341.6291-4-quentin@isovalent.com
-
由 Quentin Monnet 提交于
In bpftool's Makefile, libbpf has a FORCE dependency, to make sure we rebuild it in case its source files changed. Let's instead make the rebuild depend on the source files directly, through a call to the "$(wildcard ...)" function. This avoids descending into libbpf's directory if there is nothing to update. Do the same for the bootstrap libbpf version. This results in a slightly faster operation and less verbose output when running make a second time in bpftool's directory. Before: Auto-detecting system features: ... libbfd: [ on ] ... disassembler-four-args: [ on ] ... zlib: [ on ] ... libcap: [ on ] ... clang-bpf-co-re: [ on ] make[1]: Entering directory '/root/dev/linux/tools/lib/bpf' make[1]: Entering directory '/root/dev/linux/tools/lib/bpf' make[1]: Nothing to be done for 'install_headers'. make[1]: Leaving directory '/root/dev/linux/tools/lib/bpf' make[1]: Leaving directory '/root/dev/linux/tools/lib/bpf' After: Auto-detecting system features: ... libbfd: [ on ] ... disassembler-four-args: [ on ] ... zlib: [ on ] ... libcap: [ on ] ... clang-bpf-co-re: [ on ] Other ways to clean up the output could be to pass the "-s" option, or to redirect the output to >/dev/null, when calling make recursively to descend into libbpf's directory. However, this would suppress some useful output if something goes wrong during the build. A better alternative would be to pass "--no-print-directory" to the recursive make, but that would still leave us with some noise for "install_headers". Skipping the descent into libbpf's directory if no source file has changed works best, and seems the most logical option overall. Reported-by: NAndrii Nakryiko <andrii@kernel.org> Signed-off-by: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211009210341.6291-3-quentin@isovalent.com
-
由 Quentin Monnet 提交于
We recently updated bpftool's Makefile to make it install the headers from libbpf, instead of pulling them directly from libbpf's directory. There is also an additional header, internal to libbpf, that needs be installed. The way that bpftool's Makefile installs that particular header is currently correct, but would break if we were to modify $(LIBBPF_INTERNAL_HDRS) to make it point to more than one header. Use a static pattern rule instead, so that the Makefile can withstand the addition of other headers to install. The objective is simply to make the Makefile more robust. It should _not_ be read as an invitation to import more internal headers from libbpf into bpftool. Fixes: f012ade1 ("bpftool: Install libbpf headers instead of including the dir") Reported-by: NAndrii Nakryiko <andrii@kernel.org> Signed-off-by: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211009210341.6291-2-quentin@isovalent.com
-
由 Quentin Monnet 提交于
Although relying on some definitions from the netlink.h and if_link.h headers copied into tools/include/uapi/linux/, libbpf does not need those headers to stay entirely up-to-date with their original versions, and the warnings emitted by the Makefile when it detects a difference are usually just noise. Let's remove those warnings. Suggested-by: NAndrii Nakryiko <andrii@kernel.org> Signed-off-by: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211010002528.9772-1-quentin@isovalent.com
-
- 19 10月, 2021 1 次提交
-
-
由 Yonghong Song 提交于
Patch set [1] introduced BTF_KIND_TAG to allow tagging declarations for struct/union, struct/union field, var, func and func arguments and these tags will be encoded into dwarf. They are also encoded to btf by llvm for the bpf target. After BTF_KIND_TAG is introduced, we intended to use it for kernel __user attributes. But kernel __user is actually a type attribute. Upstream and internal discussion showed it is not a good idea to mix declaration attribute and type attribute. So we proposed to introduce btf_type_tag as a type attribute and existing btf_tag renamed to btf_decl_tag ([2]). This patch renamed BTF_KIND_TAG to BTF_KIND_DECL_TAG and some other declarations with *_tag to *_decl_tag to make it clear the tag is for declaration. In the future, BTF_KIND_TYPE_TAG might be introduced per [3]. [1] https://lore.kernel.org/bpf/20210914223004.244411-1-yhs@fb.com/ [2] https://reviews.llvm.org/D111588 [3] https://reviews.llvm.org/D111199 Fixes: b5ea834d ("bpf: Support for new btf kind BTF_KIND_TAG") Fixes: 5b84bd10 ("libbpf: Add support for BTF_KIND_TAG") Fixes: 5c07f2fe ("bpftool: Add support for BTF_KIND_TAG") Signed-off-by: NYonghong Song <yhs@fb.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211012164838.3345699-1-yhs@fb.com
-
- 09 10月, 2021 18 次提交
-
-
由 Ilya Leoshkevich 提交于
The verifier tests added in commit c48e51c8 ("bpf: selftests: Add selftests for module kfunc support") fail on s390, since the JIT does not support calling kernel functions. This is most likely an issue for all the other non-Intel arches, as well as on Intel with !CONFIG_DEBUG_INFO_BTF or !CONFIG_BPF_JIT. Trying to check for messages from all the possible add_kfunc_call() failure cases in test_verifier looks pointless, so do a much simpler thing instead: just like it's already done in do_prog_test_run(), skip the tests that fail to load with ENOTSUPP. Signed-off-by: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NSong Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20211007173329.381754-1-iii@linux.ibm.com
-
由 Yucong Sun 提交于
Change tests that often fails in parallel execution mode to serial. Signed-off-by: NYucong Sun <sunyucong@gmail.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211006185619.364369-15-fallentree@fb.com
-
由 Yucong Sun 提交于
bpf_get_current_pid_tgid() returns u64, whose upper 32 bits are the same as userspace getpid() return value. Signed-off-by: NYucong Sun <sunyucong@gmail.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211006185619.364369-13-fallentree@fb.com
-
由 Yucong Sun 提交于
This make atomics test able to run in parallel with other tests. Signed-off-by: NYucong Sun <sunyucong@gmail.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211006185619.364369-11-fallentree@fb.com
-
由 Yucong Sun 提交于
This patch change cgroup_v1v2 use a different port, avoid conflict with other tests. Signed-off-by: NYucong Sun <sunyucong@gmail.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211006185619.364369-8-fallentree@fb.com
-
由 Yucong Sun 提交于
In parallel execution mode, this test now need to use atomic operation to avoid race condition. Signed-off-by: NYucong Sun <sunyucong@gmail.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211006185619.364369-7-fallentree@fb.com
-
由 Yucong Sun 提交于
This patch make each worker use a unique cgroup base directory, thus allowing tests that uses cgroups to run concurrently. Signed-off-by: NYucong Sun <sunyucong@gmail.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211006185619.364369-5-fallentree@fb.com
-
由 Yucong Sun 提交于
This patch allows tests to define serial_test_name() instead of test_name(), and this will make test_progs execute those in sequence after all other tests finished executing concurrently. Signed-off-by: NYucong Sun <sunyucong@gmail.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211006185619.364369-3-fallentree@fb.com
-
由 Yucong Sun 提交于
This patch adds "-j" mode to test_progs, executing tests in multiple process. "-j" mode is optional, and works with all existing test selection mechanism, as well as "-v", "-l" etc. In "-j" mode, main process use UDS/SEQPACKET to communicate to each forked worker, commanding it to run tests and collect logs. After all tests are finished, a summary is printed. main process use multiple competing threads to dispatch work to worker, trying to keep them all busy. The test status will be printed as soon as it is finished, if there are error logs, it will be printed after the final summary line. By specifying "--debug", additional debug information on server/worker communication will be printed. Example output: > ./test_progs -n 15-20 -j [ 12.801730] bpf_testmod: loading out-of-tree module taints kernel. Launching 8 workers. #20 btf_split:OK #16 btf_endian:OK #18 btf_module:OK #17 btf_map_in_map:OK #19 btf_skc_cls_ingress:OK #15 btf_dump:OK Summary: 6/20 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: NYucong Sun <sunyucong@gmail.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211006185619.364369-2-fallentree@fb.com
-
由 Hou Tao 提交于
Add a writable bare tracepoint in bpf_testmod module, and trigger its calling when reading /sys/kernel/bpf_testmod with a specific buffer length. The reading will return the value in writable context if the early return flag is enabled in writable context. Signed-off-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211004094857.30868-4-hotforest@gmail.com
-
由 Hou Tao 提交于
Program on writable tracepoint is BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE, but its attachment is the same as BPF_PROG_TYPE_RAW_TRACEPOINT. Signed-off-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211004094857.30868-3-hotforest@gmail.com
-
由 Quentin Monnet 提交于
With "make install", bpftool installs its binary and its bash completion file. Usually, this is what we want. But a few components in the kernel repository (namely, BPF iterators and selftests) also install bpftool locally before using it. In such a case, bash completion is not necessary and is just a useless build artifact. Let's add an "install-bin" target to bpftool, to offer a way to install the binary only. Signed-off-by: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211007194438.34443-13-quentin@isovalent.com
-
由 Quentin Monnet 提交于
The script test_bpftool_build.sh attempts to build bpftool in the various supported ways, to make sure nothing breaks. One of those ways is to run "make tools/bpf" from the root of the kernel repository. This command builds bpftool, along with the other tools under tools/bpf, and runqslower in particular. After running the command and upon a successful bpftool build, the script attempts to cleanup the generated objects. However, after building with this target and in the case of runqslower, the files are not cleaned up as expected. This is because the "tools/bpf" target sets $(OUTPUT) to .../tools/bpf/runqslower/ when building the tool, causing the object files to be placed directly under the runqslower directory. But when running "cd tools/bpf; make clean", the value for $(OUTPUT) is set to ".output" (relative to the runqslower directory) by runqslower's Makefile, and this is where the Makefile looks for files to clean up. We cannot easily fix in the root Makefile (where "tools/bpf" is defined) or in tools/scripts/Makefile.include (setting $(OUTPUT)), where changing the way the output variables are passed would likely have consequences elsewhere. We could change runqslower's Makefile to build in the repository instead of in a dedicated ".output/", but doing so just to accommodate a test script doesn't sound great. Instead, let's just make sure that we clean up runqslower properly by adding the correct command to the script. This will attempt to clean runqslower twice: the first try with command "cd tools/bpf; make clean" will search for tools/bpf/runqslower/.output and fail to clean it (but will still clean the other tools, in particular bpftool), the second one (added in this commit) sets the $(OUTPUT) variable like for building with the "tool/bpf" target and should succeed. Signed-off-by: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211007194438.34443-12-quentin@isovalent.com
-
由 Quentin Monnet 提交于
API headers from libbpf should not be accessed directly from the library's source directory. Instead, they should be exported with "make install_headers". Let's make sure that runqslower installs the headers properly when building. We use a libbpf_hdrs target to mark the logical dependency on libbpf's headers export for a number of object files, even though the headers should have been exported at this time (since bpftool needs them, and is required to generate the skeleton or the vmlinux.h). When descending from a parent Makefile, the specific output directories for building the library and exporting the headers are configurable with BPFOBJ_OUTPUT and BPF_DESTDIR, respectively. This is in addition to OUTPUT, on top of which those variables are constructed by default. Also adjust the Makefile for the BPF selftests. We pass a number of variables to the "make" invocation, because we want to point runqslower to the (target) libbpf shared with other tools, instead of building its own version. In addition, runqslower relies on (target) bpftool, and we also want to pass the proper variables to its Makefile so that bpftool itself reuses the same libbpf. Signed-off-by: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211007194438.34443-6-quentin@isovalent.com
-
由 Quentin Monnet 提交于
API headers from libbpf should not be accessed directly from the library's source directory. Instead, they should be exported with "make install_headers". Let's make sure that resolve_btfids installs the headers properly when building. When descending from a parent Makefile, the specific output directories for building the library and exporting the headers are configurable with LIBBPF_OUT and LIBBPF_DESTDIR, respectively. This is in addition to OUTPUT, on top of which those variables are constructed by default. Also adjust the Makefile for the BPF selftests in order to point to the (target) libbpf shared with other tools, instead of building a version specific to resolve_btfids. Remove libbpf's order-only dependencies on the include directories (they are created by libbpf and don't need to exist beforehand). Signed-off-by: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211007194438.34443-5-quentin@isovalent.com
-
由 Quentin Monnet 提交于
Bpftool relies on libbpf, therefore it relies on a number of headers from the library and must be linked against the library. The Makefile for bpftool exposes these objects by adding tools/lib as an include directory ("-I$(srctree)/tools/lib"). This is a working solution, but this is not the cleanest one. The risk is to involuntarily include objects that are not intended to be exposed by the libbpf. The headers needed to compile bpftool should in fact be "installed" from libbpf, with its "install_headers" Makefile target. In addition, there is one header which is internal to the library and not supposed to be used by external applications, but that bpftool uses anyway. Adjust the Makefile in order to install the header files properly before compiling bpftool. Also copy the additional internal header file (nlattr.h), but call it out explicitly. Build (and install headers) in a subdirectory under bpftool/ instead of tools/lib/bpf/. When descending from a parent Makefile, this is configurable by setting the OUTPUT, LIBBPF_OUTPUT and LIBBPF_DESTDIR variables. Also adjust the Makefile for BPF selftests, so as to reuse the (host) libbpf compiled earlier and to avoid compiling a separate version of the library just for bpftool. Signed-off-by: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211007194438.34443-4-quentin@isovalent.com
-
由 Quentin Monnet 提交于
It seems that the header file was never necessary to compile bpftool, and it is not part of the headers exported from libbpf. Let's remove the includes from prog.c and gen.c. Fixes: d510296d ("bpftool: Use syscall/loader program in "prog load" and "gen skeleton" command.") Signed-off-by: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211007194438.34443-3-quentin@isovalent.com
-
由 Quentin Monnet 提交于
The "install_headers" target in libbpf's Makefile would unconditionally export all API headers to the target directory. When those headers are installed to compile another application, this means that make always finds newer dependencies for the source files relying on those headers, and deduces that the targets should be rebuilt. Avoid that by making "install_headers" depend on the source header files, and (re-)install them only when necessary. Signed-off-by: NQuentin Monnet <quentin@isovalent.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211007194438.34443-2-quentin@isovalent.com
-