- 11 Sep, 2024 1 commit
-
-
Andrii Nakryiko authored
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: bd7525da ("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.orgSigned-off-by:
Alexei Starovoitov <ast@kernel.org>
-
- 10 Sep, 2024 3 commits
-
-
Andrii Nakryiko authored
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] bd7525da ("bpf: Move stack_map_get_build_id into lib") Signed-off-by:
Song Liu <song@kernel.org> Acked-by:
Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20240909190426.2229940-1-andrii@kernel.orgSigned-off-by:
-
Kuan-Wei Chiu authored
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:
Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/bpf/20240910150207.3179306-1-visitorckw@gmail.com
-
Jiri Olsa authored
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:
-
- 09 Sep, 2024 6 commits
-
-
Yusheng Zheng authored
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:
-
Shahab Vahedi authored
The previous e-mail address from Synopsys is not available anymore. Signed-off-by:
Shahab Vahedi <list+bpf@vahedi.org> Signed-off-by:
-
Maxim Mikityanskiy authored
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: 00b85860 ("bpf: Rewrite kfunc argument handling") Signed-off-by:
Maxim Mikityanskiy <maxim@isovalent.com> Signed-off-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/bpf/20240909133909.1315460-1-maxim@isovalent.com
-
Andrew Kreimer authored
Fix typos in documentation. Reported-by:
Matthew Wilcox <willy@infradead.org> Reported-by:
Andrew Kreimer <algonell@gmail.com> Signed-off-by:
-
Kuan-Wei Chiu authored
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:
-
Shuyi Cheng authored
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:
-
- 06 Sep, 2024 5 commits
-
-
Sam James authored
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 (fab45b96). Signed-off-by:Sam James <sam@gentoo.org> Signed-off-by:
-
Mykyta Yatsenko authored
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:
-
Alexei Starovoitov authored
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.comSigned-off-by:
-
JP Kobryn authored
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.comSigned-off-by:
-
JP Kobryn authored
Associate tracepoint and perf event program types with the kfunc tracing hook. This allows calling kfuncs within these types of programs. Signed-off-by:
-
- 05 Sep, 2024 25 commits
-
-
Andrii Nakryiko authored
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:
-
Shung-Hsi Yu authored
Commit 980ca8ce ("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: 980ca8ce ("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:
-
Alexei Starovoitov authored
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:
-
Pu Lehui authored
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.comSigned-off-by:
-
Pu Lehui authored
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: -
Pu Lehui authored
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: -
Pu Lehui authored
Add config.riscv64 for both BPF CI and local vmtest. Tested-by:
-
Pu Lehui authored
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:
-
Pu Lehui authored
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:
-
Pu Lehui authored
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:
-
Eduard Zingerman authored
It is not always convenient to have LLVM libraries installed inside CI rootfs images, thus request static libraries from llvm-config. Suggested-by:
-
Pu Lehui authored
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 authored
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:
-
Lin Yikai authored
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.comSigned-off-by:
-
Lin Yikai authored
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 authored
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:
-
Andrii Nakryiko authored
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.orgSigned-off-by:
-
Jiri Olsa authored
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 authored
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 authored
Adding child argument to spawn_child function to allow to create multiple children in following change. Signed-off-by:
-
Jiri Olsa authored
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:
-
Andrii Nakryiko authored
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.comSigned-off-by:
-
Pu Lehui authored
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 authored
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 authored
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:
Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/bpf/20240831041934.1629216-3-pulehui@huaweicloud.com
-
