kernel/git/stable/linux.git/tools/bpf, branch linux-6.2.y

bpftool: Fix bug for long instructions in program CFG dumps

2023-05-11T14:11:12+00:00

[ Upstream commit 67cf52cdb6c8fa6365d29106555dacf95c9fd374 ] When dumping the control flow graphs for programs using the 16-byte long load instruction, we need to skip the second part of this instruction when looking for the next instruction to process. Otherwise, we end up printing "BUG_ld_00" from the kernel disassembler in the CFG. Fixes: efcef17a6d65 ("tools: bpftool: generate .dot graph from CFG information") Signed-off-by: Quentin Monnet Link: https://lore.kernel.org/r/20230405132120.59886-3-quentin@isovalent.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

tools: bpftool: Remove invalid \' json escape

2023-05-11T14:11:08+00:00

[ Upstream commit c679bbd611c08b0559ffae079330bc4e5574696a ] RFC8259 ("The JavaScript Object Notation (JSON) Data Interchange Format") only specifies \", \\, \/, \b, \f, \n, \r, and \r as valid two-character escape sequences. This does not include \', which is not required in JSON because it exclusively uses double quotes as string separators. Solidus (/) may be escaped, but does not have to. Only reverse solidus (\), double quotes ("), and the control characters have to be escaped. Therefore, with this fix, bpftool correctly supports all valid two-character escape sequences (but still does not support characters that require multi-character escape sequences). Witout this fix, attempting to load a JSON file generated by bpftool using Python 3.10.6's default json.load() may fail with the error "Invalid \escape" if the file contains the invalid escaped single quote (\'). Fixes: b66e907cfee2 ("tools: bpftool: copy JSON writer from iproute2 repository") Signed-off-by: Luis Gerhorst Signed-off-by: Andrii Nakryiko Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20230227150853.16863-1-gerhorst@cs.fau.de Signed-off-by: Sasha Levin

bpftool: Always disable stack protection for BPF objects

2023-03-10T08:29:08+00:00

[ Upstream commit 878625e1c7a10dfbb1fdaaaae2c4d2a58fbce627 ] When the clang toolchain has stack protection enabled in order to be consistent with gcc - which just happens to be the case on Gentoo - the bpftool build fails: [...] clang \ -I. \ -I/tmp/portage/dev-util/bpftool-6.0.12/work/linux-6.0/tools/include/uapi/ \ -I/tmp/portage/dev-util/bpftool-6.0.12/work/linux-6.0/tools/bpf/bpftool/bootstrap/libbpf/include \ -g -O2 -Wall -target bpf -c skeleton/pid_iter.bpf.c -o pid_iter.bpf.o clang \ -I. \ -I/tmp/portage/dev-util/bpftool-6.0.12/work/linux-6.0/tools/include/uapi/ \ -I/tmp/portage/dev-util/bpftool-6.0.12/work/linux-6.0/tools/bpf/bpftool/bootstrap/libbpf/include \ -g -O2 -Wall -target bpf -c skeleton/profiler.bpf.c -o profiler.bpf.o skeleton/profiler.bpf.c:40:14: error: A call to built-in function '__stack_chk_fail' is not supported. int BPF_PROG(fentry_XXX) ^ skeleton/profiler.bpf.c:94:14: error: A call to built-in function '__stack_chk_fail' is not supported. int BPF_PROG(fexit_XXX) ^ 2 errors generated. [...] Since stack-protector makes no sense for the BPF bits just unconditionally disable it. Bug: https://bugs.gentoo.org/890638 Signed-off-by: Holger Hoffstätte Signed-off-by: Daniel Borkmann Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/74cd9d2e-6052-312a-241e-2b514a75c92c@applied-asynchrony.com Signed-off-by: Sasha Levin

bpftool: profile online CPUs instead of possible

2023-03-10T08:28:12+00:00

[ Upstream commit 377c16fa3f3c60d21e4b05314c8be034ce37f2eb ] The number of online cpu may be not equal to possible cpu. "bpftool prog profile" can not create pmu event on possible but on online cpu. $ dmidecode -s system-product-name PowerEdge R620 $ cat /sys/devices/system/cpu/possible 0-47 $ cat /sys/devices/system/cpu/online 0-31 Disable cpu dynamically: $ echo 0 > /sys/devices/system/cpu/cpuX/online If one cpu is offline, perf_event_open will return ENODEV. To fix this issue: * check value returned and skip offline cpu. * close pmu_fd immediately on error path, avoid fd leaking. Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command") Signed-off-by: Tonghao Zhang Cc: Quentin Monnet Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Andrii Nakryiko Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: John Fastabend Cc: KP Singh Cc: Stanislav Fomichev Cc: Hao Luo Cc: Jiri Olsa Acked-by: John Fastabend Link: https://lore.kernel.org/r/20230202131701.29519-1-tong@infragraf.org Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin

bpftool: Fix linkage with statically built libllvm

2022-12-22T19:09:43+00:00

Since the commit eb9d1acf634b ("bpftool: Add LLVM as default library for disassembling JIT-ed programs") we might link the bpftool program with the libllvm library. This works fine when a shared libllvm library is available, but fails if we want to link bpftool with a statically built LLVM: [...] /usr/bin/ld: /usr/local/lib/libLLVMSupport.a(CrashRecoveryContext.cpp.o): in function `llvm::CrashRecoveryContextCleanup::~CrashRecoveryContextCleanup()': CrashRecoveryContext.cpp:(.text._ZN4llvm27CrashRecoveryContextCleanupD0Ev+0x17): undefined reference to `operator delete(void*, unsigned long)' /usr/bin/ld: /usr/local/lib/libLLVMSupport.a(CrashRecoveryContext.cpp.o): in function `llvm::CrashRecoveryContext::~CrashRecoveryContext()': CrashRecoveryContext.cpp:(.text._ZN4llvm20CrashRecoveryContextD2Ev+0xc8): undefined reference to `operator delete(void*, unsigned long)' [...] So in the case of static libllvm we need to explicitly link bpftool with required libraries, namely, libstdc++ and those provided by the `llvm-config --system-libs` command. We can distinguish between the shared and static cases by using the `llvm-config --shared-mode` command. Fixes: eb9d1acf634b ("bpftool: Add LLVM as default library for disassembling JIT-ed programs") Signed-off-by: Anton Protopopov Signed-off-by: Daniel Borkmann Acked-by: Stanislav Fomichev Link: https://lore.kernel.org/bpf/20221222102627.1643709-1-aspsk@isovalent.com

bpftool: Fix memory leak in do_build_table_cb

2022-12-06T20:20:42+00:00

strdup() allocates memory for path. We need to release the memory in the following error path. Add free() to avoid memory leak. Fixes: 8f184732b60b ("bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects") Signed-off-by: Miaoqian Lin Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20221206071906.806384-1-linmq006@gmail.com

bpftool: remove function free_btf_vmlinux()

2022-11-21T00:17:46+00:00

The function contains a single btf__free() call which can be inlined. Credits to Yonghong Song. Signed-off-by: Sahid Orentino Ferdjaoui Acked-by: Yonghong Song Suggested-by: Yonghong Song Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/r/20221120112515.38165-6-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov

bpftool: clean-up usage of libbpf_get_error()

2022-11-21T00:17:46+00:00

bpftool is now totally compliant with libbpf 1.0 mode and is not expected to be compiled with pre-1.0, let's clean-up the usage of libbpf_get_error(). The changes stay aligned with returned errors always negative. - In tools/bpf/bpftool/btf.c This fixes an uninitialized local variable `err` in function do_dump() because it may now be returned without having been set. - This also removes the checks on NULL pointers before calling btf__free() because that function already does the check. Signed-off-by: Sahid Orentino Ferdjaoui Link: https://lore.kernel.org/r/20221120112515.38165-5-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov

bpftool: fix error message when function can't register struct_ops

2022-11-21T00:17:46+00:00

It is expected that errno be passed to strerror(). This also cleans this part of code from using libbpf_get_error(). Signed-off-by: Sahid Orentino Ferdjaoui Acked-by: Yonghong Song Suggested-by: Quentin Monnet Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/r/20221120112515.38165-4-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov

bpftool: replace return value PTR_ERR(NULL) with 0

2022-11-21T00:17:46+00:00

There is no reasons to keep PTR_ERR() when kern_btf=NULL, let's just return 0. This also cleans this part of code from using libbpf_get_error(). Signed-off-by: Sahid Orentino Ferdjaoui Acked-by: Yonghong Song Suggested-by: Quentin Monnet Link: https://lore.kernel.org/r/20221120112515.38165-3-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov