linux-stable.git/tools/bpf/bpftool/map.c, branch linux-5.17.y

bpftool: Fix print error when show bpf map

2022-04-08T11:58:22+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 pretty print dump for maps without BTF loaded

2022-04-08T11:58:07+00:00

[ Upstream commit f76d8507d23834f7e56b0fe95c82605e7d7e0efe ]

The commit e5043894b21f ("bpftool: Use libbpf_get_error() to check error")
fails to dump map without BTF loaded in pretty mode (-p option).

Fixing this by making sure get_map_kv_btf won't fail in case there's
no BTF available for the map.

Fixes: e5043894b21f ("bpftool: Use libbpf_get_error() to check error")
Suggested-by: Andrii Nakryiko 
Signed-off-by: Jiri Olsa 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20220216092102.125448-1-jolsa@kernel.org
Signed-off-by: Sasha Levin

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

2022-04-08T11:58: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: Fix error check when calling hashmap__new()

2022-04-08T11:57:55+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: Migrate off of deprecated bpf_create_map_xattr() API

2021-12-02T23:23:40+00:00

Switch to bpf_map_create() API instead.

Signed-off-by: Andrii Nakryiko 
Signed-off-by: Alexei Starovoitov 
Link: https://lore.kernel.org/bpf/20211201232824.3166325-4-andrii@kernel.org

bpftool: Use libbpf_get_error() to check error

2021-11-15T02:38:13+00:00

Currently, LIBBPF_STRICT_ALL mode is enabled by default for
bpftool which means on error cases, some libbpf APIs would
return NULL pointers. This makes IS_ERR check failed to detect
such cases and result in segfault error. Use libbpf_get_error()
instead like we do in libbpf itself.

Signed-off-by: Hengqi Chen 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20211115012436.3143318-1-hengqi.chen@gmail.com

bpftool: Update the lists of names for maps and prog-attach types

2021-11-15T02:35:02+00:00

To support the different BPF map or attach types, bpftool must remain
up-to-date with the types supported by the kernel. Let's update the
lists, by adding the missing Bloom filter map type and the perf_event
attach type.

Both missing items were found with test_bpftool_synctypes.py.

Signed-off-by: Quentin Monnet 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20211110114632.24537-6-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

bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects

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

In order to show pinned paths for BPF programs, maps, or links when
listing them with the "-f" option, bpftool creates hash maps to store
all relevant paths under the bpffs. So far, it would rely on the
kernel implementation (from tools/include/linux/hashtable.h).

We can make bpftool rely on libbpf's implementation instead. 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 commit is the first step of the conversion: the hash maps for
pinned paths for programs, maps, and links are converted to libbpf's
hashmap.{c,h}. Other hash maps used for the PIDs of process holding
references to BPF objects are left unchanged for now. On the build side,
this requires adding a dependency to a second header internal to libbpf,
and making it a dependency for the bootstrap bpftool version as well.
The rest of the changes are a rather straightforward conversion.

Signed-off-by: Quentin Monnet 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20211023205154.6710-4-quentin@isovalent.com

bpftool: Do not expose and init hash maps for pinned path in main.c

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

BPF programs, maps, and links, can all be listed with their pinned paths
by bpftool, when the "-f" option is provided. To do so, bpftool builds
hash maps containing all pinned paths for each kind of objects.

These three hash maps are always initialised in main.c, and exposed
through main.h. There appear to be no particular reason to do so: we can
just as well make them static to the files that need them (prog.c,
map.c, and link.c respectively), and initialise them only when we want
to show objects and the "-f" switch is provided.

This may prevent unnecessary memory allocations if the implementation of
the hash maps was to change in the future.

Signed-off-by: Quentin Monnet 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20211023205154.6710-3-quentin@isovalent.com