summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-09-11lib/buildid: add single folio-based file reader abstractionAndrii Nakryiko1-53/+210
Add freader abstraction that transparently manages fetching and local mapping of the underlying file page(s) and provides a simple direct data access interface. freader_fetch() is the only and single interface necessary. It accepts file offset and desired number of bytes that should be accessed, and will return a kernel mapped pointer that caller can use to dereference data up to requested size. Requested size can't be bigger than the size of the extra buffer provided during initialization (because, worst case, all requested data has to be copied into it, so it's better to flag wrongly sized buffer unconditionally, regardless if requested data range is crossing page boundaries or not). If folio is not paged in, or some of the conditions are not satisfied, NULL is returned and more detailed error code can be accessed through freader->err field. This approach makes the usage of freader_fetch() cleaner. To accommodate accessing file data that crosses folio boundaries, user has to provide an extra buffer that will be used to make a local copy, if necessary. This is done to maintain a simple linear pointer data access interface. We switch existing build ID parsing logic to it, without changing or lifting any of the existing constraints, yet. This will be done separately. Given existing code was written with the assumption that it's always working with a single (first) page of the underlying ELF file, logic passes direct pointers around, which doesn't really work well with freader approach and would be limiting when removing the single page (folio) limitation. So we adjust all the logic to work in terms of file offsets. There is also a memory buffer-based version (freader_init_from_mem()) for cases when desired data is already available in kernel memory. This is used for parsing vmlinux's own build ID note. In this mode assumption is that provided data starts at "file offset" zero, which works great when parsing ELF notes sections, as all the parsing logic is relative to note section's start. Reviewed-by: Eduard Zingerman <eddyz87@gmail.com> Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20240829174232.3133883-3-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-11lib/buildid: harden build ID parsing logicAndrii Nakryiko1-32/+44
Harden build ID parsing logic, adding explicit READ_ONCE() where it's important to have a consistent value read and validated just once. Also, as pointed out by Andi Kleen, we need to make sure that entire ELF note is within a page bounds, so move the overflow check up and add an extra note_size boundaries validation. Fixes tag below points to the code that moved this code into lib/buildid.c, and then subsequently was used in perf subsystem, making this code exposed to perf_event_open() users in v5.12+. Cc: stable@vger.kernel.org Reviewed-by: Eduard Zingerman <eddyz87@gmail.com> Reviewed-by: Jann Horn <jannh@google.com> Suggested-by: Andi Kleen <ak@linux.intel.com> Fixes: bd7525dacd7e ("bpf: Move stack_map_get_build_id into lib") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20240829174232.3133883-2-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-11MAINTAINERS: record lib/buildid.c as owned by BPF subsystemAndrii Nakryiko1-0/+2
Build ID fetching code originated from ([0]), and is still both owned and heavily relied upon by BPF subsystem. Fix the original omission in [0] to record this fact in MAINTAINERS. [0] bd7525dacd7e ("bpf: Move stack_map_get_build_id into lib") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Song Liu <song@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20240909190426.2229940-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-10bpftool: Fix undefined behavior in qsort(NULL, 0, ...)Kuan-Wei Chiu1-0/+3
When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: "Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined." To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer. Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/bpf/20240910150207.3179306-1-visitorckw@gmail.com
2024-09-10libbpf: Fix uretprobe.multi.s programs auto attachmentJiri Olsa1-1/+1
As reported by Andrii we don't currently recognize uretprobe.multi.s programs as return probes due to using (wrong) strcmp function. Using str_has_pfx() instead to match uretprobe.multi prefix. Tests are passing, because the return program was executed as entry program and all counts were incremented properly. Reported-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240910125336.3056271-1-jolsa@kernel.org
2024-09-10libbpf: Fix some typos in commentsYusheng Zheng8-13/+13
Fix some spelling errors in the code comments of libbpf: betwen -> between paremeters -> parameters knowning -> knowing definiton -> definition compatiblity -> compatibility overriden -> overridden occured -> occurred proccess -> process managment -> management nessary -> necessary Signed-off-by: Yusheng Zheng <yunwei356@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240909225952.30324-1-yunwei356@gmail.com
2024-09-10MAINTAINERS: BPF ARC JIT: Update my e-mail addressShahab Vahedi1-1/+1
The previous e-mail address from Synopsys is not available anymore. Signed-off-by: Shahab Vahedi <list+bpf@vahedi.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240909184754.27634-1-list+bpf@vahedi.org
2024-09-10bpf: Fix error message on kfunc arg type mismatchMaxim Mikityanskiy4-2/+11
When "arg#%d expected pointer to ctx, but got %s" error is printed, both template parts actually point to the type of the argument, therefore, it will also say "but got PTR", regardless of what was the actual register type. Fix the message to print the register type in the second part of the template, change the existing test to adapt to the new format, and add a new test to test the case when arg is a pointer to context, but reg is a scalar. Fixes: 00b85860feb8 ("bpf: Rewrite kfunc argument handling") Signed-off-by: Maxim Mikityanskiy <maxim@isovalent.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/bpf/20240909133909.1315460-1-maxim@isovalent.com
2024-09-10bpftool: Fix typosAndrew Kreimer1-1/+1
Fix typos in documentation. Reported-by: Matthew Wilcox <willy@infradead.org> Reported-by: Quentin Monnet <qmo@kernel.org> Signed-off-by: Andrew Kreimer <algonell@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/bpf/20240909092452.4293-1-algonell@gmail.com
2024-09-10bpftool: Fix undefined behavior caused by shifting into the sign bitKuan-Wei Chiu1-4/+4
Replace shifts of '1' with '1U' in bitwise operations within __show_dev_tc_bpf() to prevent undefined behavior caused by shifting into the sign bit of a signed integer. By using '1U', the operations are explicitly performed on unsigned integers, avoiding potential integer overflow or sign-related issues. Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/bpf/20240908140009.3149781-1-visitorckw@gmail.com
2024-09-10libbpf: Fixed getting wrong return address on arm64 architectureShuyi Cheng1-1/+1
ARM64 has a separate lr register to store the return address, so here you only need to read the lr register to get the return address, no need to dereference it again. Signed-off-by: Shuyi Cheng <chengshuyi@linux.alibaba.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/1725787433-77262-1-git-send-email-chengshuyi@linux.alibaba.com
2024-09-07libbpf: Workaround (another) -Wmaybe-uninitialized false positiveSam James1-2/+2
We get this with GCC 15 -O3 (at least): ``` libbpf.c: In function ‘bpf_map__init_kern_struct_ops’: libbpf.c:1109:18: error: ‘mod_btf’ may be used uninitialized [-Werror=maybe-uninitialized] 1109 | kern_btf = mod_btf ? mod_btf->btf : obj->btf_vmlinux; | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libbpf.c:1094:28: note: ‘mod_btf’ was declared here 1094 | struct module_btf *mod_btf; | ^~~~~~~ In function ‘find_struct_ops_kern_types’, inlined from ‘bpf_map__init_kern_struct_ops’ at libbpf.c:1102:8: libbpf.c:982:21: error: ‘btf’ may be used uninitialized [-Werror=maybe-uninitialized] 982 | kern_type = btf__type_by_id(btf, kern_type_id); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libbpf.c: In function ‘bpf_map__init_kern_struct_ops’: libbpf.c:967:21: note: ‘btf’ was declared here 967 | struct btf *btf; | ^~~ ``` This is similar to the other libbpf fix from a few weeks ago for the same modelling-errno issue (fab45b962749184e1a1a57c7c583782b78fad539). Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://bugs.gentoo.org/939106 Link: https://lore.kernel.org/bpf/f6962729197ae7cdf4f6d1512625bd92f2322d31.1725630494.git.sam@gentoo.org
2024-09-07bpftool: Improve btf c dump sorting stabilityMykyta Yatsenko1-5/+75
Existing algorithm for BTF C dump sorting uses only types and names of the structs and unions for ordering. As dump contains structs with the same names but different contents, relative to each other ordering of those structs will be accidental. This patch addresses this problem by introducing a new sorting field that contains hash of the struct/union field names and types to disambiguate comparison of the non-unique named structs. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240906132453.146085-1-mykyta.yatsenko5@gmail.com
2024-09-06Merge branch 'allow-kfuncs-in-tracepoint-and-perf-event'Alexei Starovoitov2-0/+50
JP Kobryn says: ==================== allow kfuncs in tracepoint and perf event It is possible to call a cpumask kfunc within a raw tp_btf program but not possible within tracepoint or perf event programs. Currently, the verifier receives -EACCESS from fetch_kfunc_meta() as a result of not finding any kfunc hook associated with these program types. This patch series associates tracepoint and perf event program types with the tracing hook and includes test coverage. Pre-submission CI run: https://github.com/kernel-patches/bpf/pull/7674 v3: - map tracepoint and perf event progs to tracing kfunc hook - expand existing verifier tests for kfuncs - remove explicit registrations from v2 - no longer including kprobes v2: - create new kfunc hooks for tracepoint and perf event - map tracepoint, and perf event prog types to kfunc hooks - register cpumask kfuncs with prog types in focus - expand existing verifier tests for cpumask kfuncs v1: - map tracepoint type progs to tracing kfunc hook - new selftests for calling cpumask kfuncs in tracepoint prog --- ==================== Link: https://lore.kernel.org/r/20240905223812.141857-1-inwardvessel@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-06bpf/selftests: coverage for tp and perf event progs using kfuncsJP Kobryn1-0/+48
This coverage ensures that kfuncs are allowed within tracepoint and perf event programs. Signed-off-by: JP Kobryn <inwardvessel@gmail.com> Link: https://lore.kernel.org/r/20240905223812.141857-3-inwardvessel@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-06bpf: allow kfuncs within tracepoint and perf event programsJP Kobryn1-0/+2
Associate tracepoint and perf event program types with the kfunc tracing hook. This allows calling kfuncs within these types of programs. Signed-off-by: JP Kobryn <inwardvessel@gmail.com> Link: https://lore.kernel.org/r/20240905223812.141857-2-inwardvessel@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-06bpf: change int cmd argument in __sys_bpf into typed enum bpf_cmdAndrii Nakryiko1-1/+1
This improves BTF data recorded about this function and makes debugging/tracing better, because now command can be displayed as symbolic name, instead of obscure number. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20240905210520.2252984-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05bpf: use type_may_be_null() helper for nullable-param checkShung-Hsi Yu3-6/+6
Commit 980ca8ceeae6 ("bpf: check bpf_dummy_struct_ops program params for test runs") does bitwise AND between reg_type and PTR_MAYBE_NULL, which is correct, but due to type difference the compiler complains: net/bpf/bpf_dummy_struct_ops.c:118:31: warning: bitwise operation between different enumeration types ('const enum bpf_reg_type' and 'enum bpf_type_flag') [-Wenum-enum-conversion] 118 | if (info && (info->reg_type & PTR_MAYBE_NULL)) | ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ Workaround the warning by moving the type_may_be_null() helper from verifier.c into bpf_verifier.h, and reuse it here to check whether param is nullable. Fixes: 980ca8ceeae6 ("bpf: check bpf_dummy_struct_ops program params for test runs") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404241956.HEiRYwWq-lkp@intel.com/ Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20240905055233.70203-1-shung-hsi.yu@suse.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05Merge branch 'local-vmtest-enhancement-and-rv64-enabled'Alexei Starovoitov7-45/+205
Pu Lehui says: ==================== Local vmtest enhancement and RV64 enabled Patch 1-3 fix some problem about bpf selftests. Patch 4 add local rootfs image support for vmtest. Patch 5 enable cross-platform testing for vmtest. Patch 6-10 enable vmtest on RV64. We can now perform cross platform testing for riscv64 bpf using the following command: PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \ tools/testing/selftests/bpf/vmtest.sh \ -l <path of local rootfs image> -- \ ./test_progs -d \ \"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \ | cut -d'#' -f1 \ | sed -e 's/^[[:space:]]*//' \ -e 's/[[:space:]]*$//' \ | tr -s '\n' ',' \ )\" For better regression, we rely on commit [0]. And since the work of riscv ftrace to remove stop_machine atomic replacement is in progress, we also need to revert commit [1] [2]. The test platform is x86_64 architecture, and the versions of relevant components are as follows: QEMU: 8.2.0 CLANG: 17.0.6 (align to BPF CI) ROOTFS: ubuntu noble (generated by [3]) Link: https://lore.kernel.org/all/20240831071520.1630360-1-pulehui@huaweicloud.com/ [0] Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3308172276db [1] Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7caa9765465f [2] Link: https://github.com/libbpf/ci/blob/main/rootfs/mkrootfs_debian.sh [3] v3: - Use llvm static linking when detecting that feature-llvm is enabled - Add Acked-by by Eduard v2: https://lore.kernel.org/all/20240904141951.1139090-1-pulehui@huaweicloud.com/ - Drop patch about relaxing Zbb insns restrictions. - Add local rootfs image support - Add description about running vmtest on RV64 - Fix some problem about bpf selftests v1: https://lore.kernel.org/all/20240328124916.293173-1-pulehui@huaweicloud.com/ ==================== Acked-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20240905081401.1894789-1-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: Add description for running vmtest on RV64Pu Lehui1-0/+32
Add description in tools/testing/selftests/bpf/README.rst for running vmtest on RV64. Signed-off-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/r/20240905081401.1894789-11-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: Add riscv64 configurations to local vmtestPu Lehui1-0/+9
Add riscv64 configurations to local vmtest. We can now perform cross platform testing for riscv64 bpf using the following command: PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- vmtest.sh \ -l ./libbpf-vmtest-rootfs-2024.08.30-noble-riscv64.tar.zst -- \ ./test_progs -d \ \"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \ | cut -d'#' -f1 \ | sed -e 's/^[[:space:]]*//' \ -e 's/[[:space:]]*$//' \ | tr -s '\n' ','\ )\" Tested-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/r/20240905081401.1894789-10-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: Add DENYLIST.riscv64Pu Lehui1-0/+3
This patch adds DENYLIST.riscv64 file for riscv64. It will help BPF CI and local vmtest to mask failing and unsupported test cases. We can use the following command to use deny list in local vmtest as previously mentioned by Manu. PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- vmtest.sh \ -l ./libbpf-vmtest-rootfs-2024.08.30-noble-riscv64.tar.zst -- \ ./test_progs -d \ \"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \ | cut -d'#' -f1 \ | sed -e 's/^[[:space:]]*//' \ -e 's/[[:space:]]*$//' \ | tr -s '\n' ','\ )\" Tested-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/r/20240905081401.1894789-9-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: Add config.riscv64Pu Lehui1-0/+84
Add config.riscv64 for both BPF CI and local vmtest. Tested-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/r/20240905081401.1894789-8-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: Enable cross platform testing for vmtestPu Lehui1-11/+31
Add support cross platform testing for vmtest. The variable $ARCH in the current script is platform semantics, not kernel semantics. Rename it to $PLATFORM so that we can easily use $ARCH in cross-compilation. And drop `set -u` unbound variable check as we will use CROSS_COMPILE env variable. For now, Using PLATFORM= and CROSS_COMPILE= options will enable cross platform testing: PLATFORM=<platform> CROSS_COMPILE=<toolchain> vmtest.sh -- ./test_progs Tested-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/r/20240905081401.1894789-7-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: Support local rootfs image for vmtestPu Lehui2-7/+16
Support vmtest to use local rootfs image generated by [0] that is consistent with BPF CI. Now we can specify the local rootfs image through the `-l` parameter like as follows: vmtest.sh -l ./libbpf-vmtest-rootfs-2024.08.22-noble-amd64.tar.zst -- ./test_progs Meanwhile, some descriptions have been flushed. Link: https://github.com/libbpf/ci/blob/main/rootfs/mkrootfs_debian.sh [0] Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/r/20240905081401.1894789-6-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: Limit URLS parsing logic to actual scope in vmtestPu Lehui1-20/+19
The URLS array is only valid in the download_rootfs function and does not need to be parsed globally in advance. At the same time, the logic of loading rootfs is refactored to prepare vmtest for supporting local rootfs. Signed-off-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/r/20240905081401.1894789-5-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: Prefer static linking for LLVM librariesEduard Zingerman1-5/+3
It is not always convenient to have LLVM libraries installed inside CI rootfs images, thus request static libraries from llvm-config. Suggested-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20240905081401.1894789-4-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: Rename fallback in bpf_dctcp to avoid naming conflictPu Lehui2-5/+5
Recently, when compiling bpf selftests on RV64, the following compilation failure occurred: progs/bpf_dctcp.c:29:21: error: redefinition of 'fallback' as different kind of symbol 29 | volatile const char fallback[TCP_CA_NAME_MAX]; | ^ /workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:86812:15: note: previous definition is here 86812 | typedef u32 (*fallback)(u32, const unsigned char *, size_t); The reason is that the `fallback` symbol has been defined in arch/riscv/lib/crc32.c, which will cause symbol conflicts when vmlinux.h is included in bpf_dctcp. Let we rename `fallback` string to `fallback_cc` in bpf_dctcp to fix this compilation failure. Signed-off-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/r/20240905081401.1894789-3-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: Adapt OUTPUT appending logic to lower versions of MakePu Lehui1-0/+6
The $(let ...) function is only supported by GNU Make version 4.4 [0] and above, otherwise the following exception file or directory will be generated: tools/testing/selftests/bpfFEATURE-DUMP.selftests tools/testing/selftests/bpffeature/ Considering that the GNU Make version of most Linux distributions is lower than 4.4, let us adapt the corresponding logic to it. Link: https://lists.gnu.org/archive/html/info-gnu/2022-10/msg00008.html [0] Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/r/20240905081401.1894789-2-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05libbpf: fix some typos in libbpfLin Yikai6-9/+9
Hi, fix some spelling errors in libbpf, the details are as follows: -in the code comments: termintaing->terminating architecutre->architecture requring->requiring recored->recoded sanitise->sanities allowd->allowed abover->above see bpf_udst_arg()->see bpf_usdt_arg() Signed-off-by: Lin Yikai <yikai.lin@vivo.com> Link: https://lore.kernel.org/r/20240905110354.3274546-3-yikai.lin@vivo.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05bpftool: fix some typos in bpftoolLin Yikai2-6/+6
Hi, fix some spelling errors in bpftool, the details are as follows: -in file "bpftool-gen.rst" libppf->libbpf -in the code comments: ouptut->output Signed-off-by: Lin Yikai <yikai.lin@vivo.com> Link: https://lore.kernel.org/r/20240905110354.3274546-2-yikai.lin@vivo.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05selftests/bpf: fix some typos in selftestsLin Yikai25-39/+39
Hi, fix some spelling errors in selftest, the details are as follows: -in the codes: test_bpf_sk_stoarge_map_iter_fd(void) ->test_bpf_sk_storage_map_iter_fd(void) load BTF from btf_data.o->load BTF from btf_data.bpf.o -in the code comments: preample->preamble multi-contollers->multi-controllers errono->errno unsighed/unsinged->unsigned egree->egress shoud->should regsiter->register assummed->assumed conditiona->conditional rougly->roughly timetamp->timestamp ingores->ignores null-termainted->null-terminated slepable->sleepable implemenation->implementation veriables->variables timetamps->timestamps substitue a costant->substitute a constant secton->section unreferened->unreferenced verifer->verifier libppf->libbpf ... Signed-off-by: Lin Yikai <yikai.lin@vivo.com> Link: https://lore.kernel.org/r/20240905110354.3274546-1-yikai.lin@vivo.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05Merge branch 'selftests-bpf-add-uprobe-multi-pid-filter-test'Andrii Nakryiko3-59/+177
Jiri Olsa says: ==================== selftests/bpf: Add uprobe multi pid filter test hi, sending fix for uprobe multi pid filtering together with tests. The first version included tests for standard uprobes, but as we still do not have fix for that, sending just uprobe multi changes. thanks, jirka v2 changes: - focused on uprobe multi only, removed perf event uprobe specific parts - added fix and test for CLONE_VM process filter --- ==================== Link: https://lore.kernel.org/r/20240905115124.1503998-1-jolsa@kernel.org Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2024-09-05selftests/bpf: Add uprobe multi pid filter test for clone-ed processesJiri Olsa1-24/+42
The idea is to run same test as for test_pid_filter_process, but instead of standard fork-ed process we create the process with clone(CLONE_VM..) to make sure the thread leader process filter works properly in this case. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240905115124.1503998-5-jolsa@kernel.org
2024-09-05selftests/bpf: Add uprobe multi pid filter test for fork-ed processesJiri Olsa2-0/+107
The idea is to create and monitor 3 uprobes, each trigered in separate process and make sure the bpf program gets executed just for the proper PID specified via pid filter. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240905115124.1503998-4-jolsa@kernel.org
2024-09-05selftests/bpf: Add child argument to spawn_child functionJiri Olsa1-46/+39
Adding child argument to spawn_child function to allow to create multiple children in following change. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240905115124.1503998-3-jolsa@kernel.org
2024-09-05bpf: Fix uprobe multi pid filter checkJiri Olsa1-1/+1
Uprobe multi link does its own process (thread leader) filtering before running the bpf program by comparing task's vm pointers. But as Oleg pointed out there can be processes sharing the vm (CLONE_VM), so we can't just compare task->vm pointers, but instead we need to use same_thread_group call. Suggested-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/bpf/20240905115124.1503998-2-jolsa@kernel.org
2024-09-05Merge branch 'fix-accessing-first-syscall-argument-on-rv64'Andrii Nakryiko3-11/+12
Pu Lehui says: ==================== Fix accessing first syscall argument on RV64 On RV64, as Ilya mentioned before [0], the first syscall parameter should be accessed through orig_a0 (see arch/riscv64/include/asm/syscall.h), otherwise it will cause selftests like bpf_syscall_macro, vmlinux, test_lsm, etc. to fail on RV64. Link: https://lore.kernel.org/bpf/20220209021745.2215452-1-iii@linux.ibm.com [0] v3: - Fix test case error. v2: https://lore.kernel.org/all/20240831023646.1558629-1-pulehui@huaweicloud.com/ - Access first syscall argument with CO-RE direct read. (Andrii) v1: https://lore.kernel.org/all/20240829133453.882259-1-pulehui@huaweicloud.com/ ==================== Link: https://lore.kernel.org/r/20240831041934.1629216-1-pulehui@huaweicloud.com Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2024-09-05libbpf: Fix accessing first syscall argument on RV64Pu Lehui1-1/+8
On RV64, as Ilya mentioned before [0], the first syscall parameter should be accessed through orig_a0 (see arch/riscv64/include/asm/syscall.h), otherwise it will cause selftests like bpf_syscall_macro, vmlinux, test_lsm, etc. to fail on RV64. Let's fix it by using the struct pt_regs style CO-RE direct access. Signed-off-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20220209021745.2215452-1-iii@linux.ibm.com [0] Link: https://lore.kernel.org/bpf/20240831041934.1629216-5-pulehui@huaweicloud.com
2024-09-05selftests/bpf: Enable test_bpf_syscall_macro: Syscall_arg1 on s390 and arm64Pu Lehui2-6/+0
Considering that CO-RE direct read access to the first system call argument is already available on s390 and arm64, let's enable test_bpf_syscall_macro:syscall_arg1 on these architectures. Signed-off-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240831041934.1629216-4-pulehui@huaweicloud.com
2024-09-05libbpf: Access first syscall argument with CO-RE direct read on arm64Pu Lehui1-2/+2
Currently PT_REGS_PARM1 SYSCALL(x) is consistent with PT_REGS_PARM1_CORE SYSCALL(x), which will introduce the overhead of BPF_CORE_READ(), taking into account the read pt_regs comes directly from the context, let's use CO-RE direct read to access the first system call argument. Suggested-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/bpf/20240831041934.1629216-3-pulehui@huaweicloud.com
2024-09-05libbpf: Access first syscall argument with CO-RE direct read on s390Pu Lehui1-2/+2
Currently PT_REGS_PARM1 SYSCALL(x) is consistent with PT_REGS_PARM1_CORE SYSCALL(x), which will introduce the overhead of BPF_CORE_READ(), taking into account the read pt_regs comes directly from the context, let's use CO-RE direct read to access the first system call argument. Suggested-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240831041934.1629216-2-pulehui@huaweicloud.com
2024-09-05selftests/bpf: Add a selftest for x86 jit convergence issuesYonghong Song2-0/+116
The core part of the selftest, i.e., the je <-> jmp cycle, mimics the original sched-ext bpf program. The test will fail without the previous patch. I tried to create some cases for other potential cycles (je <-> je, jmp <-> je and jmp <-> jmp) with similar pattern to the test in this patch, but failed. So this patch only contains one test for je <-> jmp cycle. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20240904221256.37389-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-05bpf, x64: Fix a jit convergence issueYonghong Song1-2/+52
Daniel Hodges reported a jit error when playing with a sched-ext program. The error message is: unexpected jmp_cond padding: -4 bytes But further investigation shows the error is actual due to failed convergence. The following are some analysis: ... pass4, final_proglen=4391: ... 20e: 48 85 ff test rdi,rdi 211: 74 7d je 0x290 213: 48 8b 77 00 mov rsi,QWORD PTR [rdi+0x0] ... 289: 48 85 ff test rdi,rdi 28c: 74 17 je 0x2a5 28e: e9 7f ff ff ff jmp 0x212 293: bf 03 00 00 00 mov edi,0x3 Note that insn at 0x211 is 2-byte cond jump insn for offset 0x7d (-125) and insn at 0x28e is 5-byte jmp insn with offset -129. pass5, final_proglen=4392: ... 20e: 48 85 ff test rdi,rdi 211: 0f 84 80 00 00 00 je 0x297 217: 48 8b 77 00 mov rsi,QWORD PTR [rdi+0x0] ... 28d: 48 85 ff test rdi,rdi 290: 74 1a je 0x2ac 292: eb 84 jmp 0x218 294: bf 03 00 00 00 mov edi,0x3 Note that insn at 0x211 is 6-byte cond jump insn now since its offset becomes 0x80 based on previous round (0x293 - 0x213 = 0x80). At the same time, insn at 0x292 is a 2-byte insn since its offset is -124. pass6 will repeat the same code as in pass4. pass7 will repeat the same code as in pass5, and so on. This will prevent eventual convergence. Passes 1-14 are with padding = 0. At pass15, padding is 1 and related insn looks like: 211: 0f 84 80 00 00 00 je 0x297 217: 48 8b 77 00 mov rsi,QWORD PTR [rdi+0x0] ... 24d: 48 85 d2 test rdx,rdx The similar code in pass14: 211: 74 7d je 0x290 213: 48 8b 77 00 mov rsi,QWORD PTR [rdi+0x0] ... 249: 48 85 d2 test rdx,rdx 24c: 74 21 je 0x26f 24e: 48 01 f7 add rdi,rsi ... Before generating the following insn, 250: 74 21 je 0x273 "padding = 1" enables some checking to ensure nops is either 0 or 4 where #define INSN_SZ_DIFF (((addrs[i] - addrs[i - 1]) - (prog - temp))) nops = INSN_SZ_DIFF - 2 In this specific case, addrs[i] = 0x24e // from pass14 addrs[i-1] = 0x24d // from pass15 prog - temp = 3 // from 'test rdx,rdx' in pass15 so nops = -4 and this triggers the failure. To fix the issue, we need to break cycles of je <-> jmp. For example, in the above case, we have 211: 74 7d je 0x290 the offset is 0x7d. If 2-byte je insn is generated only if the offset is less than 0x7d (<= 0x7c), the cycle can be break and we can achieve the convergence. I did some study on other cases like je <-> je, jmp <-> je and jmp <-> jmp which may cause cycles. Those cases are not from actual reproducible cases since it is pretty hard to construct a test case for them. the results show that the offset <= 0x7b (0x7b = 123) should be enough to cover all cases. This patch added a new helper to generate 8-bit cond/uncond jmp insns only if the offset range is [-128, 123]. Reported-by: Daniel Hodges <hodgesd@meta.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20240904221251.37109-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-04selftests: bpf: Replace sizeof(arr)/sizeof(arr[0]) with ARRAY_SIZEFeng Yang10-12/+20
The ARRAY_SIZE macro is more compact and more formal in linux source. Signed-off-by: Feng Yang <yangfeng@kylinos.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240903072559.292607-1-yangfeng59949@163.com
2024-09-04Merge branch 'bpf-follow-up-on-gen_epilogue'Alexei Starovoitov2-43/+44
Martin KaFai Lau says: ==================== bpf: Follow up on gen_epilogue From: Martin KaFai Lau <martin.lau@kernel.org> The set addresses some follow ups on the earlier gen_epilogue patch set. ==================== Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20240904180847.56947-1-martin.lau@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-04bpf: Fix indentation issue in epilogue_idxMartin KaFai Lau1-1/+1
There is a report on new indentation issue in epilogue_idx. This patch fixed it. Fixes: 169c31761c8d ("bpf: Add gen_epilogue to bpf_verifier_ops") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202408311622.4GzlzN33-lkp@intel.com/ Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://lore.kernel.org/r/20240904180847.56947-3-martin.lau@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-04bpf: Remove the insn_buf array stack usage from the inline_bpf_loop()Martin KaFai Lau2-42/+43
This patch removes the insn_buf array stack usage from the inline_bpf_loop(). Instead, the env->insn_buf is used. The usage in inline_bpf_loop() needs more than 16 insn, so the INSN_BUF_SIZE needs to be increased from 16 to 32. The compiler stack size warning on the verifier is gone after this change. Cc: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://lore.kernel.org/r/20240904180847.56947-2-martin.lau@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-04samples/bpf: Remove sample tracex2Rong Tao3-289/+0
In commit ba8de796baf4 ("net: introduce sk_skb_reason_drop function") kfree_skb_reason() becomes an inline function and cannot be traced. samples/bpf is abandonware by now, and we should slowly but surely convert whatever makes sense into BPF selftests under tools/testing/selftests/bpf and just get rid of the rest. Link: https://github.com/torvalds/linux/commit/ba8de796baf4bdc03530774fb284fe3c97875566 Signed-off-by: Rong Tao <rongtao@cestc.cn> Link: https://lore.kernel.org/r/tencent_30ADAC88CB2915CA57E9512D4460035BA107@qq.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-09-04selftests/bpf: Fix procmap_query()'s params mismatch and compilation warningYuan Chen1-2/+2
When the PROCMAP_QUERY is not defined, a compilation error occurs due to the mismatch of the procmap_query()'s params, procmap_query() only be called in the file where the function is defined, modify the params so they can match. We get a warning when build samples/bpf: trace_helpers.c:252:5: warning: no previous prototype for ‘procmap_query’ [-Wmissing-prototypes] 252 | int procmap_query(int fd, const void *addr, __u32 query_flags, size_t *start, size_t *offset, int *flags) | ^~~~~~~~~~~~~ As this function is only used in the file, mark it as 'static'. Fixes: 4e9e07603ecd ("selftests/bpf: make use of PROCMAP_QUERY ioctl if available") Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Link: https://lore.kernel.org/r/20240903012839.3178-1-chenyuan_fl@163.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-24 05:46:47 +0300