linux-stable.git/tools/lib, branch v5.17.2

libbpf: Define BTF_KIND_* constants in btf.h to avoid compilation errors

2022-04-08T11:59:00+00:00

commit eaa266d83a3730a15de2ceebcc89e8f6290e8cf6 upstream.

The btf.h header included with libbpf contains inline helper functions to
check for various BTF kinds. These helpers directly reference the
BTF_KIND_* constants defined in the kernel header, and because the header
file is included in user applications, this happens in the user application
compile units.

This presents a problem if a user application is compiled on a system with
older kernel headers because the constants are not available. To avoid
this, add #defines of the constants directly in btf.h before using them.

Since the kernel header moved to an enum for BTF_KIND_*, the #defines can
shadow the enum values without any errors, so we only need #ifndef guards
for the constants that predates the conversion to enum. We group these so
there's only one guard for groups of values that were added together.

  [0] Closes: https://github.com/libbpf/libbpf/issues/436

Fixes: 223f903e9c83 ("bpf: Rename BTF_KIND_TAG to BTF_KIND_DECL_TAG")
Fixes: 5b84bd10363e ("libbpf: Add support for BTF_KIND_TAG")
Signed-off-by: Toke Høiland-Jørgensen 
Signed-off-by: Andrii Nakryiko 
Acked-by: Arnaldo Carvalho de Melo 
Link: https://lore.kernel.org/bpf/20220118141327.34231-1-toke@redhat.com
Signed-off-by: Greg Kroah-Hartman

libperf tests: Fix typo in perf_evlist__open() failure error messages

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

[ Upstream commit c2eeac985657f61543e6c5a333b94f3bd18e6b9d ]

This patch corrects typos in error messages. I should be "evlist", not
"evsel" as the function that fails is perf_evlist__open().

Fixes: 3ce311afb5583cf3 ("libperf: Move to tools/lib/perf")
Fixes: a7f3713f6bf207e6 ("libperf tests: Add test_stat_multiplexing test")
Signed-off-by: Shunsuke Nakamura 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lore.kernel.org/lkml/20220325043829.224045-2-nakamura.shun@fujitsu.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin

libbpf: Unmap rings when umem deleted

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

[ Upstream commit 9c6e6a80ee741adf6cb3cfd8eef7d1554f91fceb ]

xsk_umem__create() does mmap for fill/comp rings, but xsk_umem__delete()
doesn't do the unmap. This works fine for regular cases, because
xsk_socket__delete() does unmap for the rings. But for the case that
xsk_socket__create_shared() fails, umem rings are not unmapped.

fill_save/comp_save are checked to determine if rings have already be
unmapped by xsk. If fill_save and comp_save are NULL, it means that the
rings have already been used by xsk. Then they are supposed to be
unmapped by xsk_socket__delete(). Otherwise, xsk_umem__delete() does the
unmap.

Fixes: 2f6324a3937f ("libbpf: Support shared umems between queues and devices")
Signed-off-by: Cheng Li 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20220301132623.GA19995@vscode.7~
Signed-off-by: Sasha Levin

libbpf: Skip forward declaration when counting duplicated type names

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

[ Upstream commit 4226961b0019b2e1612029e8950a9e911affc995 ]

Currently if a declaration appears in the BTF before the definition, the
definition is dumped as a conflicting name, e.g.:

    $ bpftool btf dump file vmlinux format raw | grep "'unix_sock'"
    [81287] FWD 'unix_sock' fwd_kind=struct
    [89336] STRUCT 'unix_sock' size=1024 vlen=14

    $ bpftool btf dump file vmlinux format c | grep "struct unix_sock"
    struct unix_sock;
    struct unix_sock___2 {	<--- conflict, the "___2" is unexpected
		    struct unix_sock___2 *unix_sk;

This causes a compilation error if the dump output is used as a header file.

Fix it by skipping declaration when counting duplicated type names.

Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion")
Signed-off-by: Xu Kuohai 
Signed-off-by: Daniel Borkmann 
Acked-by: Song Liu 
Link: https://lore.kernel.org/bpf/20220301053250.1464204-2-xukuohai@huawei.com
Signed-off-by: Sasha Levin

libbpf: Fix BPF_MAP_TYPE_PERF_EVENT_ARRAY auto-pinning

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

[ Upstream commit a4fbfdd7a160eccaafc093eb5b34f838b1ca0bf0 ]

When a BPF map of type BPF_MAP_TYPE_PERF_EVENT_ARRAY doesn't have the
max_entries parameter set, the map will be created with max_entries set
to the number of available CPUs. When we try to reuse such a pinned map,
map_is_reuse_compat will return false, as max_entries in the map
definition differs from max_entries of the existing map, causing the
following error:

  libbpf: couldn't reuse pinned map at '/sys/fs/bpf/m_logging': parameter mismatch

Fix this by overwriting max_entries in the map definition. For this to
work, we need to do this in bpf_object__create_maps, before calling
bpf_object__reuse_map.

Fixes: 57a00f41644f ("libbpf: Add auto-pinning of maps when loading BPF objects")
Signed-off-by: Stijn Tintel 
Signed-off-by: Daniel Borkmann 
Acked-by: Song Liu 
Link: https://lore.kernel.org/bpf/20220225152355.315204-1-stijn@linux-ipv6.be
Signed-off-by: Sasha Levin

libbpf: Fix memleak in libbpf_netlink_recv()

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

[ Upstream commit 1b8c924a05934d2e758ec7da7bd217ef8ebd80ce ]

Ensure that libbpf_netlink_recv() frees dynamically allocated buffer in
all code paths.

Fixes: 9c3de619e13e ("libbpf: Use dynamically allocated buffer when receiving netlink messages")
Signed-off-by: Andrii Nakryiko 
Signed-off-by: Daniel Borkmann 
Acked-by: Toke Høiland-Jørgensen 
Link: https://lore.kernel.org/bpf/20220217073958.276959-1-andrii@kernel.org
Signed-off-by: Sasha Levin

libbpf: Use dynamically allocated buffer when receiving netlink messages

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

[ Upstream commit 9c3de619e13ee6693ec5ac74f50b7aa89056a70e ]

When receiving netlink messages, libbpf was using a statically allocated
stack buffer of 4k bytes. This happened to work fine on systems with a 4k
page size, but on systems with larger page sizes it can lead to truncated
messages. The user-visible impact of this was that libbpf would insist no
XDP program was attached to some interfaces because that bit of the netlink
message got chopped off.

Fix this by switching to a dynamically allocated buffer; we borrow the
approach from iproute2 of using recvmsg() with MSG_PEEK|MSG_TRUNC to get
the actual size of the pending message before receiving it, adjusting the
buffer as necessary. While we're at it, also add retries on interrupted
system calls around the recvmsg() call.

v2:
  - Move peek logic to libbpf_netlink_recv(), don't double free on ENOMEM.

Fixes: 8bbb77b7c7a2 ("libbpf: Add various netlink helpers")
Reported-by: Zhiqian Guan 
Signed-off-by: Toke Høiland-Jørgensen 
Signed-off-by: Andrii Nakryiko 
Acked-by: Kumar Kartikeya Dwivedi 
Link: https://lore.kernel.org/bpf/20220211234819.612288-1-toke@redhat.com
Signed-off-by: Sasha Levin

libbpf: Fix libbpf.map inheritance chain for LIBBPF_0.7.0

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

[ Upstream commit d130e954a002b901391037c33b9ae11bae5aaa91 ]

Ensure that LIBBPF_0.7.0 inherits everything from LIBBPF_0.6.0.

Fixes: dbdd2c7f8cec ("libbpf: Add API to get/set log_level at per-program level")
Signed-off-by: Andrii Nakryiko 
Signed-off-by: Alexei Starovoitov 
Link: https://lore.kernel.org/bpf/20220211205235.2089104-1-andrii@kernel.org
Signed-off-by: Sasha Levin

libbpf: Fix compilation warning due to mismatched printf format

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

[ Upstream commit dc37dc617fabfb1c3a16d49f5d8cc20e9e3608ca ]

On ppc64le architecture __s64 is long int and requires %ld. Cast to
ssize_t and use %zd to avoid architecture-specific specifiers.

Fixes: 4172843ed4a3 ("libbpf: Fix signedness bug in btf_dump_array_data()")
Signed-off-by: Andrii Nakryiko 
Signed-off-by: Daniel Borkmann 
Link: https://lore.kernel.org/bpf/20220209063909.1268319-1-andrii@kernel.org
Signed-off-by: Sasha Levin

libbpf: Fix riscv register names

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

[ Upstream commit 5c101153bfd67387ba159b7864176217a40757da ]

riscv registers are accessed via struct user_regs_struct, not struct
pt_regs. The program counter member in this struct is called pc, not
epc. The frame pointer is called s0, not fp.

Fixes: 3cc31d794097 ("libbpf: Normalize PT_REGS_xxx() macro definitions")
Signed-off-by: Ilya Leoshkevich 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20220209021745.2215452-6-iii@linux.ibm.com
Signed-off-by: Sasha Levin