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

bpftool: Fix print error when show bpf map

2022-04-08T12:06:19+00:00

[ Upstream commit 1824d8ea75f275a5e69e5f6bc0ffe122ea9b938c ] If there is no btf_id or frozen, it will not show the pids, but the pids don't depend on any one of them. Below is the result after this change: $ ./bpftool map show 2: lpm_trie flags 0x1 key 8B value 8B max_entries 1 memlock 4096B pids systemd(1) 3: lpm_trie flags 0x1 key 20B value 8B max_entries 1 memlock 4096B pids systemd(1) While before this change, the 'pids systemd(1)' can't be displayed. Fixes: 9330986c0300 ("bpf: Add bloom filter map implementation") Signed-off-by: Yafang Shao Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220320060815.7716-1-laoar.shao@gmail.com Signed-off-by: Sasha Levin

bpftool: Fix the error when lookup in no-btf maps

2022-04-08T12:06:06+00:00

[ Upstream commit edc21dc909c6c133a2727f063eadd7907af51f94 ] When reworking btf__get_from_id() in commit a19f93cfafdf the error handling when calling bpf_btf_get_fd_by_id() changed. Before the rework if bpf_btf_get_fd_by_id() failed the error would not be propagated to callers of btf__get_from_id(), after the rework it is. This lead to a change in behavior in print_key_value() that now prints an error when trying to lookup keys in maps with no btf available. Fix this by following the way used in dumping maps to allow to look up keys in no-btf maps, by which it decides whether and where to get the btf info according to the btf value type. Fixes: a19f93cfafdf ("libbpf: Add internal helper to load BTF data by FD") Signed-off-by: Yinjun Zhang Signed-off-by: Simon Horman Signed-off-by: Andrii Nakryiko Reviewed-by: Niklas Söderlund Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/1644249625-22479-1-git-send-email-yinjun.zhang@corigine.com Signed-off-by: Sasha Levin

bpftool: Only set obj->skeleton on complete success

2022-04-08T12:05:57+00:00

[ Upstream commit 0991f6a38f576aa9a5e34713e23c998a3310d4d0 ] After `bpftool gen skeleton`, the ${bpf_app}.skel.h will provide that ${bpf_app_name}__open helper to load bpf. If there is some error like ENOMEM, the ${bpf_app_name}__open will rollback(free) the allocated object, including `bpf_object_skeleton`. Since the ${bpf_app_name}__create_skeleton set the obj->skeleton first and not rollback it when error, it will cause double-free in ${bpf_app_name}__destory at ${bpf_app_name}__open. Therefore, we should set the obj->skeleton before return 0; Fixes: 5dc7a8b21144 ("bpftool, selftests/bpf: Embed object file inside skeleton") Signed-off-by: Wei Fu Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220108084008.1053111-1-fuweid89@gmail.com Signed-off-by: Sasha Levin

bpftool: Fix error check when calling hashmap__new()

2022-04-08T12:05:57+00:00

[ Upstream commit 622a5b582cc27d3deedc38fcef68da2972e8e58d ] hashmap__new() encodes errors with ERR_PTR(), hence it's not valid to check the returned pointer against NULL and IS_ERR() has to be used instead. libbpf_get_error() can't be used in this case as hashmap__new() is not part of the public libbpf API and it'll continue using ERR_PTR() after libbpf 1.0. Fixes: 8f184732b60b ("bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects") Fixes: 2828d0d75b73 ("bpftool: Switch to libbpf's hashmap for programs/maps in BTF listing") Fixes: d6699f8e0f83 ("bpftool: Switch to libbpf's hashmap for PIDs/names references") Signed-off-by: Mauricio Vásquez Signed-off-by: Andrii Nakryiko Reviewed-by: Quentin Monnet Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20220107152620.192327-2-mauricio@kinvolk.io Signed-off-by: Sasha Levin

bpftool: Fix indent in option lists in the documentation

2022-01-27T11:02:54+00:00

commit 986dec18bbf41f50edc2e0aa4ac5ef8e0f64f328 upstream. Mixed indentation levels in the lists of options in bpftool's documentation produces some unexpected results. For the "bpftool" man page, it prints a warning: $ make -C bpftool.8 GEN bpftool.8 :26: (ERROR/3) Unexpected indentation. For other pages, there is no warning, but it results in a line break appearing in the option lists in the generated man pages. RST paragraphs should have a uniform indentation level. Let's fix it. Fixes: c07ba629df97 ("tools: bpftool: Update and synchronise option list in doc and help msg") Fixes: 8cc8c6357c8f ("tools: bpftool: Document and add bash completion for -L, -B options") Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20211110114632.24537-5-quentin@isovalent.com Signed-off-by: Greg Kroah-Hartman

bpftool: Remove inclusion of utilities.mak from Makefiles

2022-01-27T11:02:54+00:00

commit 48f5aef4c458c19ab337eed8c95a6486cc014aa3 upstream. Bpftool's Makefile, and the Makefile for its documentation, both include scripts/utilities.mak, but they use none of the items defined in this file. Remove the includes. Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20211110114632.24537-3-quentin@isovalent.com Signed-off-by: Greg Kroah-Hartman

bpftool: Enable line buffering for stdout

2022-01-27T11:01:51+00:00

[ Upstream commit 1a1a0b0364ad291bd8e509da104ac8b5b1afec5d ] The output of bpftool prog tracelog is currently buffered, which is inconvenient when piping the output into other commands. A simple tracelog | grep will typically not display anything. This patch fixes it by enabling line buffering on stdout for the whole bpftool binary. Fixes: 30da46b5dc3a ("tools: bpftool: add a command to dump the trace pipe") Signed-off-by: Quentin Monnet Signed-off-by: Paul Chaignon Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20211220214528.GA11706@Mem Signed-off-by: Sasha Levin

bpftool: Fix memory leak in prog_dump()

2022-01-27T11:01:28+00:00

[ Upstream commit ebbd7f64a3fbe9e0f235e39fc244ee9735e2a52a ] Following the extraction of prog_dump() from do_dump(), the struct btf allocated in prog_dump() is no longer freed on error; the struct bpf_prog_linfo is not freed at all. Make sure we release them before exiting the function. Fixes: ec2025095cf6 ("bpftool: Match several programs with same tag") Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20211110114632.24537-2-quentin@isovalent.com Signed-off-by: Sasha Levin

bpftool: Install libbpf headers for the bootstrap version, too

2021-11-05T15:19:48+00:00

We recently changed bpftool's Makefile to make it install libbpf's headers locally instead of pulling them from the source directory of the library. Although bpftool needs two versions of libbpf, a "regular" one and a "bootstrap" version, we would only install headers for the regular libbpf build. Given that this build always occurs before the bootstrap build when building bpftool, this is enough to ensure that the bootstrap bpftool will have access to the headers exported through the regular libbpf build. However, this did not account for the case when we only want the bootstrap version of bpftool, through the "bootstrap" target. For example, perf needs the bootstrap version only, to generate BPF skeletons. In that case, when are the headers installed? For some time, the issue has been masked, because we had a step (the installation of headers internal to libbpf) which would depend on the regular build of libbpf and hence trigger the export of the headers, just for the sake of creating a directory. But this changed with commit 8b6c46241c77 ("bpftool: Remove Makefile dep. on $(LIBBPF) for $(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed the dependency on the regular libbpf build. As a result, when we only want the bootstrap bpftool version, the regular libbpf is no longer built. The bootstrap libbpf version is built, but headers are not exported, and the bootstrap bpftool build fails because of the missing headers. To fix this, we also install the library headers for the bootstrap version of libbpf, to use them for the bootstrap bpftool and for generating the skeletons. Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir") Reported-by: Arnaldo Carvalho de Melo Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Tested-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com

bpftool: Switch to libbpf's hashmap for PIDs/names references

2021-10-26T00:31:39+00:00

In order to show PIDs and names for processes holding references to BPF programs, maps, links, or BTF objects, bpftool creates hash maps to store all relevant information. This commit is part of a set that transitions from the kernel's hash map implementation to the one coming with libbpf. The motivation is to make bpftool less dependent of kernel headers, to ease the path to a potential out-of-tree mirror, like libbpf has. This is the third and final step of the transition, in which we convert the hash maps used for storing the information about the processes holding references to BPF objects (programs, maps, links, BTF), and at last we drop the inclusion of tools/include/linux/hashtable.h. Note: Checkpatch complains about the use of __weak declarations, and the missing empty lines after the bunch of empty function declarations when compiling without the BPF skeletons (none of these were introduced in this patch). We want to keep things as they are, and the reports should be safe to ignore. Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20211023205154.6710-6-quentin@isovalent.com