Select Git revision
Search by author
- Any Author
- authors
-
Adrien Ricciardi
RICCIARDI-Adrien-BayLibre
-
Alexandre Bailon abailon
-
Andrew Stubbs
ams
-
Anne Françoise Gros afgros
-
BayLibreCI baylibreCI
-
Bernhard Rosenkränzer
bero
-
Carlo Caione carlo.caione
-
Christophe Baylibre
BLChristopheCBO
-
Drew Fustini dfustini
-
Guillaume LA ROQUE glaroque
-
Guillaume Pain gpain
-
Guillaume Ranquet granquet
-
Jeremy Robinson jrobinson
-
Jerome Brunet
jbrunet
-
Julien Masson
JulienMasson
-
Julien Morin
jmorin2
-
Julien Stephan jstephan
-
Jérémie Garcia jgarcia
-
Kevin Hilman khilman
-
Markus Schneider-Pargmann msp8
- Feb 17, 2023
-
-
Ilya Leoshkevich authored
Use the new type-safe wrappers around bpf_obj_get_info_by_fd(). Split the bpf_obj_get_info_by_fd() call in build_btf_type_table() in two, since knowing the type helps with the Memory Sanitizer. Improve map_parse_fd_and_info() type safety by using struct bpf_map_info * instead of void * for info. Signed-off-by:
Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Reviewed-by:
Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20230214231221.249277-4-iii@linux.ibm.com
-
- Feb 11, 2023
-
-
Ilya Leoshkevich authored
This makes it possible to add sanitizer flags. Signed-off-by:
-
- Feb 09, 2023
-
-
Jiri Olsa authored
Thorsten reported build issue with command line that defined extra HOSTCFLAGS that were not passed into 'prepare' targets, but were used to build resolve_btfids objects. This results in build fail when these objects are linked together: /usr/bin/ld: /build.../tools/bpf/resolve_btfids//libbpf/libbpf.a(libbpf-in.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE \ object; recompile with -fPIE Fixing this by passing HOSTCFLAGS in EXTRA_CFLAGS as part of HOST_OVERRIDES variable for prepare targets. [1] https://lore.kernel.org/bpf/f7922132-6645-6316-5675-0ece4197bfff@leemhuis.info/ Fixes: 56a2df76 ("tools/resolve_btfids: Compile resolve_btfids as host program") Reported-by:
Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/bpf/20230209143735.4112845-1-jolsa@kernel.org
-
- Feb 07, 2023
-
-
Ian Rogers authored
Don't set EXTRA_CFLAGS to HOSTCFLAGS, ensure CROSS_COMPILE isn't passed through. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
-
Jiri Olsa authored
Making resolve_btfids to be compiled as host program so we can avoid cross compile issues as reported by Nathan. Also we no longer need HOST_OVERRIDES for BINARY target, just for 'prepare' targets. Fixes: 13e07691 ("tools/resolve_btfids: Alter how HOSTCC is forced") Reported-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
- Feb 03, 2023
-
-
Tonghao Zhang authored
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: 47c09d6a ("bpftool: Introduce "prog profile" command") Signed-off-by:
Tonghao Zhang <tong@infragraf.org> Cc: Quentin Monnet <quentin@isovalent.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Martin KaFai Lau <martin.lau@linux.dev> Cc: Song Liu <song@kernel.org> Cc: Yonghong Song <yhs@fb.com> Cc: John Fastabend <john.fastabend@gmail.com> Cc: KP Singh <kpsingh@kernel.org> Cc: Stanislav Fomichev <sdf@google.com> Cc: Hao Luo <haoluo@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Acked-by:
John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20230202131701.29519-1-tong@infragraf.org Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org>
-
- Jan 25, 2023
-
-
Ian Rogers authored
HOSTCC is always wanted when building. Setting CC to HOSTCC happens after tools/scripts/Makefile.include is included, meaning flags are set assuming say CC is gcc, but then it can be later set to HOSTCC which may be clang. tools/scripts/Makefile.include is needed for host set up and common macros in objtool's Makefile. Rather than override CC to HOSTCC, just pass CC as HOSTCC to Makefile.build, the libsubcmd builds and the linkage step. This means the Makefiles don't see things like CC changing and tool flag determination, and similar, work properly. Also, clear the passed subdir as otherwise an outer build may break by inadvertently passing an inappropriate value. Signed-off-by:
-
Ian Rogers authored
Previously tools/lib/subcmd was added to the include path, switch to installing the headers and then including from that directory. This avoids dependencies on headers internal to tools/lib/subcmd. Add the missing subcmd directory to the affected #include. Signed-off-by:
-
- Jan 13, 2023
-
-
Holger Hoffstätte authored
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 <holger@applied-asynchrony.com> Signed-off-by:
-
- Jan 11, 2023
-
-
Chethan Suresh authored
When bpftool feature does not find kernel config files under default path or wrong format, do not output CONFIG_XYZ is not set. Skip kernel config check and continue. Signed-off-by:
Chethan Suresh <chethan.suresh@sony.com> Signed-off-by:
Kenta Tada <Kenta.Tada@sony.com> Acked-by:
-
- Jan 10, 2023
-
-
James Hilliard authored
When passing compiler variables like CC=$(HOSTCC) to a submake we must ensure the variable is quoted in order to handle cases where $(HOSTCC) may be multiple binaries. For example when using ccache $HOSTCC may be: "/usr/bin/ccache /usr/bin/gcc" If we pass CC without quotes like CC=$(HOSTCC) only the first "/usr/bin/ccache" part will be assigned to the CC variable which will cause an error due to dropping the "/usr/bin/gcc" part of the variable in the submake invocation. This fixes errors such as: /usr/bin/ccache: invalid option -- 'd' Signed-off-by:
James Hilliard <james.hilliard1@gmail.com> Signed-off-by:
-
- Dec 22, 2022
-
-
Anton Protopopov authored
Since the commit eb9d1acf ("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: eb9d1acf ("bpftool: Add LLVM as default library for disassembling JIT-ed programs") Signed-off-by:
Anton Protopopov <aspsk@isovalent.com> Signed-off-by:
Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/bpf/20221222102627.1643709-1-aspsk@isovalent.com
-
- Dec 21, 2022
-
-
Changbin Du authored
Remove the empty vmlinux.h if bpftool failed to dump btf info. The empty vmlinux.h can hide real error when reading output of make. This is done by adding .DELETE_ON_ERROR special target in related makefiles. Signed-off-by:
Changbin Du <changbin.du@gmail.com> Signed-off-by:
-
- Dec 15, 2022
-
-
Shen Jiamin authored
When libelf was not installed in the standard location, it cannot be located by the current building config. Use pkg-config to help locate libelf in such cases. Signed-off-by:
Shen Jiamin <shen_jiamin@comp.nus.edu.sg> Signed-off-by:
-
- Dec 06, 2022
-
-
Miaoqian Lin authored
strdup() allocates memory for path. We need to release the memory in the following error path. Add free() to avoid memory leak. Fixes: 8f184732 ("bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Signed-off-by:
-
- Nov 21, 2022
-
-
Sahid Orentino Ferdjaoui authored
The function contains a single btf__free() call which can be inlined. Credits to Yonghong Song. Signed-off-by:
Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Acked-by:
Yonghong Song <yhs@fb.com> Suggested-by:
Alexei Starovoitov <ast@kernel.org>
-
Sahid Orentino Ferdjaoui authored
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 authored
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 authored
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 authored
Following: commit bd054102 ("libbpf: enforce strict libbpf 1.0 behaviors") commit 93b8952d ("libbpf: deprecate legacy BPF map definitions") The --legacy option is no longer relevant as libbpf no longer supports it. libbpf_set_strict_mode() is a no-op operation. Signed-off-by:
-
- Nov 16, 2022
-
-
Tiezhu Yang authored
If the parameters for batch are more than 2, check argc first can return immediately, no need to use is_prefix() to check "file" with a little overhead and then check argc, it is better to check "file" only when the parameters for batch are 2. Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Acked-by:
-
- Nov 10, 2022
-
-
Eduard Zingerman authored
An update for libbpf's hashmap interface from void* -> void* to a polymorphic one, allowing both long and void* keys and values. This simplifies many use cases in libbpf as hashmaps there are mostly integer to integer. Perf copies hashmap implementation from libbpf and has to be updated as well. Changes to libbpf, selftests/bpf and perf are packed as a single commit to avoid compilation issues with any future bisect. Polymorphic interface is acheived by hiding hashmap interface functions behind auxiliary macros that take care of necessary type casts, for example: #define hashmap_cast_ptr(p) \ ({ \ _Static_assert((p) == NULL || sizeof(*(p)) == sizeof(long),\ #p " pointee should be a long-sized integer or a pointer"); \ (long *)(p); \ }) bool hashmap_find(const struct hashmap *map, long key, long *value); #define hashmap__find(map, key, value) \ hashmap_find((map), (long)(key), hashmap_cast_ptr(value)) - hashmap__find macro casts key and value parameters to long and long* respectively - hashmap_cast_ptr ensures that value pointer points to a memory of appropriate size. This hack was suggested by Andrii Nakryiko in [1]. This is a follow up for [2]. [1] https://lore.kernel.org/bpf/CAEf4BzZ8KFneEJxFAaNCCFPGqp20hSpS2aCj76uRk3-qZUH5xg@mail.gmail.com/ [2] https://lore.kernel.org/bpf/af1facf9-7bc8-8a3d-0db4-7b3f333589a2@meta.com/T/#m65b28f1d6d969fcd318b556db6a3ad499a42607d Signed-off-by:Eduard Zingerman <eddyz87@gmail.com> Signed-off-by:
-
- Nov 02, 2022
-
-
Pu Lehui authored
When using bpftool to pin {PROG, MAP, LINK} without FILE, segmentation fault will occur. The reson is that the lack of FILE will cause strlen to trigger NULL pointer dereference. The corresponding stacktrace is shown below: do_pin do_pin_any do_pin_fd mount_bpffs_for_pin strlen(name) <- NULL pointer dereference Fix it by adding validation to the common process. Fixes: 75a1e792 ("tools: bpftool: Allow all prog/map handles for pinning objects") Signed-off-by:Pu Lehui <pulehui@huawei.com> Signed-off-by:
-
- Oct 27, 2022
-
-
Colin Ian King authored
There is a spelling mistake in an error message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Acked-by:
-
- Oct 26, 2022
-
-
Yonghong Song authored
Add support for new cgroup local storage Acked-by:
-
- Oct 25, 2022
-
-
Quentin Monnet authored
Similarly to "libbfd", add a "llvm" feature to the output of command "bpftool version" to indicate that LLVM is used for disassembling JIT-ed programs. This feature is mutually exclusive (from Makefile definitions) with "libbfd". Signed-off-by:
Niklas Söderlund <niklas.soderlund@corigine.com> Acked-by:
-
Quentin Monnet authored
For offloaded BPF programs, instead of failing to create the LLVM disassembler without even looking for a triple at all, do run the function that attempts to retrieve a valid architecture name for the device. It will still fail for the LLVM disassembler, because currently we have no valid triple to return (NFP disassembly is not supported by LLVM). But failing in that function is more logical than to assume in jit_disasm.c that passing an "arch" name is simply not supported. Suggested-by:
Song Liu <song@kernel.org> Signed-off-by:
-
Quentin Monnet authored
To disassemble instructions for JIT-ed programs, bpftool has relied on the libbfd library. This has been problematic in the past: libbfd's interface is not meant to be stable and has changed several times. For building bpftool, we have to detect how the libbfd version on the system behaves, which is why we have to handle features disassembler-four-args and disassembler-init-styled in the Makefile. When it comes to shipping bpftool, this has also caused issues with several distribution maintainers unwilling to support the feature (see for example Debian's page for binutils-dev, which ships libbfd: "Note that building Debian packages which depend on the shared libbfd is Not Allowed." [0]). For these reasons, we add support for LLVM as an alternative to libbfd for disassembling instructions of JIT-ed programs. Thanks to the preparation work in the previous commits, it's easy to add the library by passing the relevant compilation options in the Makefile, and by adding the functions for setting up the LLVM disassembler in file jit_disasm.c. The LLVM disassembler requires the LLVM development package (usually llvm-dev or llvm-devel). The expectation is that the interface for this disassembler will be more stable. There is a note in LLVM's Developer Policy [1] stating that the stability for the C API is "best effort" and not guaranteed, but at least there is some effort to keep compatibility when possible (which hasn't really been the case for libbfd so far). Furthermore, the Debian page for the related LLVM package does not caution against linking to the lib, as binutils-dev page does. Naturally, the display of disassembled instructions comes with a few minor differences. Here is a sample output with libbfd (already supported before this patch): # bpftool prog dump jited id 56 bpf_prog_6deef7357e7b4530: 0: nopl 0x0(%rax,%rax,1) 5: xchg %ax,%ax 7: push %rbp 8: mov %rsp,%rbp b: push %rbx c: push %r13 e: push %r14 10: mov %rdi,%rbx 13: movzwq 0xb4(%rbx),%r13 1b: xor %r14d,%r14d 1e: or $0x2,%r14d 22: mov $0x1,%eax 27: cmp $0x2,%r14 2b: jne 0x000000000000002f 2d: xor %eax,%eax 2f: pop %r14 31: pop %r13 33: pop %rbx 34: leave 35: ret LLVM supports several variants that we could set when initialising the disassembler, for example with: LLVMSetDisasmOptions(*ctx, LLVMDisassembler_Option_AsmPrinterVariant); but the default printer is used for now. Here is the output with LLVM: # bpftool prog dump jited id 56 bpf_prog_6deef7357e7b4530: 0: nopl (%rax,%rax) 5: nop 7: pushq %rbp 8: movq %rsp, %rbp b: pushq %rbx c: pushq %r13 e: pushq %r14 10: movq %rdi, %rbx 13: movzwq 180(%rbx), %r13 1b: xorl %r14d, %r14d 1e: orl $2, %r14d 22: movl $1, %eax 27: cmpq $2, %r14 2b: jne 0x2f 2d: xorl %eax, %eax 2f: popq %r14 31: popq %r13 33: popq %rbx 34: leave 35: retq The LLVM disassembler comes as the default choice, with libbfd as a fall-back. Of course, we could replace libbfd entirely and avoid supporting two different libraries. One reason for keeping libbfd is that, right now, it works well, we have all we need in terms of features detection in the Makefile, so it provides a fallback for disassembling JIT-ed programs if libbfd is installed but LLVM is not. The other motivation is that libbfd supports nfp instruction for Netronome's SmartNICs and can be used to disassemble offloaded programs, something that LLVM cannot do. If libbfd's interface breaks again in the future, we might reconsider keeping support for it. [0] https://packages.debian.org/buster/binutils-dev [1] https://llvm.org/docs/DeveloperPolicy.html#c-api-changes Signed-off-by: -
Quentin Monnet authored
Refactor disasm_print_insn() to extract the code specific to libbfd and move it to dedicated functions. There is no functional change. This is in preparation for supporting an alternative library for disassembling the instructions. Signed-off-by:
-
Quentin Monnet authored
Bpftool uses libbfd for disassembling JIT-ed programs. But the feature is optional, and the tool can be compiled without libbfd support. The Makefile sets the relevant variables accordingly. It also sets variables related to libbfd's interface, given that it has changed over time. Group all those libbfd-related definitions so that it's easier to understand what we are testing for, and only use variables related to libbfd's interface if we need libbfd in the first place. In addition to make the Makefile clearer, grouping the definitions related to disassembling JIT-ed programs will help support alternatives to libbfd. Signed-off-by:
-
Quentin Monnet authored
Make FEATURE_TESTS and FEATURE_DISPLAY easier to read and less likely to be subject to conflicts on updates by having one feature per line. Suggested-by:
Andres Freund <andres@anarazel.de> Signed-off-by:
-
Quentin Monnet authored
The JIT disassembler in bpftool is the only components (with the JSON writer) using asserts to check the return values of functions. But it does not do so in a consistent way, and diasm_print_insn() returns no value, although sometimes the operation failed. Remove the asserts, and instead check the return values, print messages on errors, and propagate the error to the caller from prog.c. Remove the inclusion of assert.h from jit_disasm.c, and also from map.c where it is unused. Signed-off-by:
-
Quentin Monnet authored
_GNU_SOURCE is defined in several source files for bpftool, but only one of them takes the precaution of checking whether the value is already defined. Add #ifndef for other occurrences too. This is in preparation for the support of disassembling JIT-ed programs with LLVM, with $(llvm-config --cflags) passing -D_GNU_SOURCE as a compilation argument. Signed-off-by:
-
- Oct 21, 2022
-
-
Quentin Monnet authored
Along with the version number, "bpftool version" displays a list of features that were selected at compilation time for bpftool. It would be useful to indicate in that list whether a binary is a bootstrap version of bpftool. Given that an increasing number of components rely on bootstrap versions for generating skeletons, this could help understand what a binary is capable of if it has been copied outside of the usual "bootstrap" directory. To detect a bootstrap version, we simply rely on the absence of implementation for the do_prog() function. To do this, we must move the (unchanged) list of commands before do_version(), which in turn requires renaming this "cmds" array to avoid shadowing it with the "cmds" argument in cmd_select(). Signed-off-by:
-
Quentin Monnet authored
Commands "bpftool help" or "bpftool version" use argv[0] to display the name of the binary. While it is a convenient way to retrieve the string, it does not always produce the most readable output. For example, because of the way bpftool is currently packaged on Ubuntu (using a wrapper script), the command displays the absolute path for the binary: $ bpftool version | head -n 1 /usr/lib/linux-tools/5.15.0-50-generic/bpftool v5.15.60 More generally, there is no apparent reason for keeping the whole path and exact binary name in this output. If the user wants to understand what binary is being called, there are other ways to do so. This commit replaces argv[0] with "bpftool", to simply reflect what the tool is called. This is aligned on what "ip" or "tc" do, for example. As an additional benefit, this seems to help with integration with Meson for packaging [0]. [0] https://github.com/NixOS/nixpkgs/pull/195934 Suggested-by:Vladimír Čunát <vladimir.cunat@nic.cz> Signed-off-by:
-
Wang Yufen authored
Add autoattach optional to prog load|loadall for supporting one-step load-attach-pin_link. Signed-off-by:
Wang Yufen <wangyufen@huawei.com> Link: https://lore.kernel.org/r/1665736275-28143-4-git-send-email-wangyufen@huawei.com Signed-off-by:
-
Wang Yufen authored
Add autoattach optional to prog load|loadall for supporting one-step load-attach-pin_link. Signed-off-by:
-
Wang Yufen authored
Add autoattach optional to support one-step load-attach-pin_link. For example, $ bpftool prog loadall test.o /sys/fs/bpf/test autoattach $ bpftool link 26: tracing name test1 tag f0da7d0058c00236 gpl loaded_at 2022-09-09T21:39:49+0800 uid 0 xlated 88B jited 55B memlock 4096B map_ids 3 btf_id 55 28: kprobe name test3 tag 002ef1bef0723833 gpl loaded_at 2022-09-09T21:39:49+0800 uid 0 xlated 88B jited 56B memlock 4096B map_ids 3 btf_id 55 57: tracepoint name oncpu tag 7aa55dfbdcb78941 gpl loaded_at 2022-09-09T21:41:32+0800 uid 0 xlated 456B jited 265B memlock 4096B map_ids 17,13,14,15 btf_id 82 $ bpftool link 1: tracing prog 26 prog_type tracing attach_type trace_fentry 3: perf_event prog 28 10: perf_event prog 57 The autoattach optional can support tracepoints, k(ret)probes, u(ret)probes. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
- Oct 01, 2022
-
-
Tianyi Liu authored
strerror() expects a positive errno, however variable err will never be positive when an error occurs. This causes bpftool to output too many "unknown error", even a simple "file not exist" error can not get an accurate message. This patch fixed all "strerror(err)" patterns in bpftool. Specially in btf.c#L823, hashmap__append() is an internal function of libbpf and will not change errno, so there's a little difference. Some libbpf_get_error() calls are kept for return values. Changes since v1: https://lore.kernel.org/bpf/SY4P282MB1084B61CD8671DFA395AA8579D539@SY4P282MB1084.AUSP282.PROD.OUTLOOK.COM/ Check directly for NULL values instead of calling libbpf_get_error(). Signed-off-by:
Tianyi Liu <i.pear@outlook.com> Signed-off-by:
-
- Sep 30, 2022
-
-
Yuan Can authored
After commit 9b190f18 ("tools/bpftool: switch map event_pipe to libbpf's perf_buffer"), struct event_ring_info is not used any more and can be removed as well. Signed-off-by:
Yuan Can <yuancan@huawei.com> Signed-off-by:
-
