linux-stable.git/tools/bpf, branch linux-6.11.y

bpf, bpftool: Fix incorrect disasm pc

2024-12-05T12:53:19+00:00

[ Upstream commit 4d99e509c161f8610de125202c648fa4acd00541 ]

This patch addresses the bpftool issue "Wrong callq address displayed"[0].

The issue stemmed from an incorrect program counter (PC) value used during
disassembly with LLVM or libbfd.

For LLVM: The PC argument must represent the actual address in the kernel
to compute the correct relative address.

For libbfd: The relative address can be adjusted by adding func_ksym within
the custom info->print_address_func to yield the correct address.

Links:
[0] https://github.com/libbpf/bpftool/issues/109

Changes:
v2 -> v3:
  * Address comment from Quentin:
    * Remove the typedef.

v1 -> v2:
  * Fix the broken libbfd disassembler.

Fixes: e1947c750ffe ("bpftool: Refactor disassembler for JIT-ed programs")
Signed-off-by: Leon Hwang 
Signed-off-by: Andrii Nakryiko 
Tested-by: Quentin Monnet 
Reviewed-by: Quentin Monnet 
Acked-by: Yonghong Song 
Link: https://lore.kernel.org/bpf/20241031152844.68817-1-leon.hwang@linux.dev
Signed-off-by: Sasha Levin

bpftool: Fix undefined behavior in qsort(NULL, 0, ...)

2024-10-10T10:03:40+00:00

[ Upstream commit f04e2ad394e2755d0bb2d858ecb5598718bf00d5 ]

When netfilter has no entry to display, qsort is called with
qsort(NULL, 0, ...). This results in undefined behavior, as UBSan
reports:

net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null

Although the C standard does not explicitly state whether calling qsort
with a NULL pointer when the size is 0 constitutes undefined behavior,
Section 7.1.4 of the C standard (Use of library functions) mentions:

"Each of the following statements applies unless explicitly stated
otherwise in the detailed descriptions that follow: If an argument to a
function has an invalid value (such as a value outside the domain of
the function, or a pointer outside the address space of the program, or
a null pointer, or a pointer to non-modifiable storage when the
corresponding parameter is not const-qualified) or a type (after
promotion) not expected by a function with variable number of
arguments, the behavior is undefined."

To avoid this, add an early return when nf_link_info is NULL to prevent
calling qsort with a NULL pointer.

Signed-off-by: Kuan-Wei Chiu 
Signed-off-by: Andrii Nakryiko 
Reviewed-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20240910150207.3179306-1-visitorckw@gmail.com
Signed-off-by: Sasha Levin

bpftool: Fix undefined behavior caused by shifting into the sign bit

2024-10-10T10:03:40+00:00

[ Upstream commit 4cdc0e4ce5e893bc92255f5f734d983012f2bc2e ]

Replace shifts of '1' with '1U' in bitwise operations within
__show_dev_tc_bpf() to prevent undefined behavior caused by shifting
into the sign bit of a signed integer. By using '1U', the operations
are explicitly performed on unsigned integers, avoiding potential
integer overflow or sign-related issues.

Signed-off-by: Kuan-Wei Chiu 
Signed-off-by: Andrii Nakryiko 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20240908140009.3149781-1-visitorckw@gmail.com
Signed-off-by: Sasha Levin

bpftool: Fix handling enum64 in btf dump sorting

2024-10-04T14:37:59+00:00

[ Upstream commit b0222d1d9e6f8551a056b89b0bff38f515f3c9b5 ]

Wrong function is used to access the first enum64 element. Substituting btf_enum(t)
with btf_enum64(t) for BTF_KIND_ENUM64.

Fixes: 94133cf24bb3 ("bpftool: Introduce btf c dump sorting")
Signed-off-by: Mykyta Yatsenko 
Signed-off-by: Daniel Borkmann 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20240902171721.105253-1-mykyta.yatsenko5@gmail.com
Signed-off-by: Sasha Levin

tools/runqslower: Fix LDFLAGS and add LDLIBS support

2024-10-04T14:37:52+00:00

[ Upstream commit f86601c3661946721e8f260bdd812b759854ac22 ]

Actually use previously defined LDFLAGS during build and add support for
LDLIBS to link extra standalone libraries e.g. 'argp' which is not provided
by musl libc.

Fixes: 585bf4640ebe ("tools: runqslower: Add EXTRA_CFLAGS and EXTRA_LDFLAGS support")
Signed-off-by: Tony Ambardar 
Signed-off-by: Andrii Nakryiko 
Acked-by: Ilya Leoshkevich 
Link: https://lore.kernel.org/bpf/20240723003045.2273499-1-tony.ambardar@gmail.com
Signed-off-by: Sasha Levin

tools/resolve_btfids: Fix comparison of distinct pointer types warning in resolve_btfids

2024-07-22T14:35:30+00:00

Add a type cast for set8->pairs to fix below compile warning:

main.c: In function 'sets_patch':
main.c:699:50: warning: comparison of distinct pointer types lacks a cast
  699 |        BUILD_BUG_ON(set8->pairs != &set8->pairs[0].id);
      |                                 ^~

Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h")
Signed-off-by: Liwei Song 
Signed-off-by: Daniel Borkmann 
Acked-by: Jiri Olsa 
Link: https://lore.kernel.org/bpf/20240722083305.4009723-1-liwei.song.lsong@gmail.com

bpftool: Fix typo in usage help

2024-07-17T20:45:58+00:00

The usage help for "bpftool prog help" contains a ° instead of the _
symbol for cgroup/sendmsg_unix. Fix the typo.

Fixes: 8b3cba987e6d ("bpftool: Add support for cgroup unix socket address hooks")
Signed-off-by: Donald Hunter 
Signed-off-by: Daniel Borkmann 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20240717134508.77488-1-donald.hunter@gmail.com

bpftool: improve skeleton backwards compat with old buggy libbpfs

2024-07-10T02:03:05+00:00

Old versions of libbpf don't handle varying sizes of bpf_map_skeleton
struct correctly. As such, BPF skeleton generated by newest bpftool
might not be compatible with older libbpf (though only when libbpf is
used as a shared library), even though it, by design, should.

Going forward libbpf will be fixed, plus we'll release bug fixed
versions of relevant old libbpfs, but meanwhile try to mitigate from
bpftool side by conservatively assuming older and smaller definition of
bpf_map_skeleton, if possible. Meaning, if there are no struct_ops maps.

If there are struct_ops, then presumably user would like to have
auto-attaching logic and struct_ops map link placeholders, so use the
full bpf_map_skeleton definition in that case.

Acked-by: Quentin Monnet 
Co-developed-by: Mykyta Yatsenko 
Signed-off-by: Mykyta Yatsenko 
Signed-off-by: Andrii Nakryiko 
Acked-by: Eduard Zingerman 
Link: https://lore.kernel.org/r/20240708204540.4188946-2-andrii@kernel.org
Signed-off-by: Alexei Starovoitov

bpftool: Mount bpffs when pinmaps path not under the bpffs

2024-07-02T16:20:32+00:00

As Quentin said [0], BPF map pinning will fail if the pinmaps path is not
under the bpffs, like:

  libbpf: specified path /home/ubuntu/test/sock_ops_map is not on BPF FS
  Error: failed to pin all maps

  [0] https://github.com/libbpf/bpftool/issues/146

Fixes: 3767a94b3253 ("bpftool: add pinmaps argument to the load/loadall")
Signed-off-by: Tao Chen 
Signed-off-by: Daniel Borkmann 
Tested-by: Quentin Monnet 
Reviewed-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20240702131150.15622-1-chen.dylane@gmail.com

bpftool: Allow compile-time checks of BPF map auto-attach support in skeleton

2024-06-21T17:53:09+00:00

New versions of bpftool now emit additional link placeholders for BPF
maps (struct_ops maps are the only maps right now that support
attachment), and set up BPF skeleton in such a way that libbpf will
auto-attach BPF maps automatically, assumming libbpf is recent enough
(v1.5+). Old libbpf will do nothing with those links and won't attempt
to auto-attach maps. This allows user code to handle both pre-v1.5 and
v1.5+ versions of libbpf at runtime, if necessary.

But if users don't have (or don't want to) control bpftool version that
generates skeleton, then they can't just assume that skeleton will have
link placeholders. To make this detection possible and easy, let's add
the following to generated skeleton header file:

  #define BPF_SKEL_SUPPORTS_MAP_AUTO_ATTACH 1

This can be used during compilation time to guard code that accesses
skel->links. slots.

Note, if auto-attachment is undesirable, libbpf allows to disable this
through bpf_map__set_autoattach(map, false). This is necessary only on
libbpf v1.5+, older libbpf doesn't support map auto-attach anyways.

Libbpf version can be detected at compilation time using
LIBBPF_MAJOR_VERSION and LIBBPF_MINOR_VERSION macros, or at runtime with
libbpf_major_version() and libbpf_minor_version() APIs.

Signed-off-by: Andrii Nakryiko 
Signed-off-by: Daniel Borkmann 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20240618183832.2535876-1-andrii@kernel.org