linux-stable.git/tools/bpf, branch v6.6.26

tools/resolve_btfids: Fix cross-compilation to non-host endianness

2024-03-26T22:19:27+00:00

[ Upstream commit 903fad4394666bc23975c93fb58f137ce64b5192 ]

The .BTF_ids section is pre-filled with zeroed BTF ID entries during the
build and afterwards patched by resolve_btfids with correct values.
Since resolve_btfids always writes in host-native endianness, it relies
on libelf to do the translation when the target ELF is cross-compiled to
a different endianness (this was introduced in commit 61e8aeda9398
("bpf: Fix libelf endian handling in resolv_btfids")).

Unfortunately, the translation will corrupt the flags fields of SET8
entries because these were written during vmlinux compilation and are in
the correct endianness already. This will lead to numerous selftests
failures such as:

    $ sudo ./test_verifier 502 502
    #502/p sleepable fentry accept FAIL
    Failed to load prog 'Invalid argument'!
    bpf_fentry_test1 is not sleepable
    verification time 34 usec
    stack depth 0
    processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
    Summary: 0 PASSED, 0 SKIPPED, 1 FAILED

Since it's not possible to instruct libelf to translate just certain
values, let's manually bswap the flags (both global and entry flags) in
resolve_btfids when needed, so that libelf then translates everything
correctly.

Fixes: ef2c6f370a63 ("tools/resolve_btfids: Add support for 8-byte BTF sets")
Signed-off-by: Viktor Malik 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/7b6bff690919555574ce0f13d2a5996cacf7bf69.1707223196.git.vmalik@redhat.com
Signed-off-by: Sasha Levin

tools/resolve_btfids: Refactor set sorting with types from btf_ids.h

2024-03-26T22:19:27+00:00

[ Upstream commit 9707ac4fe2f5bac6406d2403f8b8a64d7b3d8e43 ]

Instead of using magic offsets to access BTF ID set data, leverage types
from btf_ids.h (btf_id_set and btf_id_set8) which define the actual
layout of the data. Thanks to this change, set sorting should also
continue working if the layout changes.

This requires to sync the definition of 'struct btf_id_set8' from
include/linux/btf_ids.h to tools/include/linux/btf_ids.h. We don't sync
the rest of the file at the moment, b/c that would require to also sync
multiple dependent headers and we don't need any other defs from
btf_ids.h.

Signed-off-by: Viktor Malik 
Signed-off-by: Andrii Nakryiko 
Acked-by: Daniel Xu 
Link: https://lore.kernel.org/bpf/ff7f062ddf6a00815fda3087957c4ce667f50532.1707223196.git.vmalik@redhat.com
Stable-dep-of: 903fad439466 ("tools/resolve_btfids: Fix cross-compilation to non-host endianness")
Signed-off-by: Sasha Levin

bpftool: Silence build warning about calloc()

2024-03-26T22:19:22+00:00

[ Upstream commit f5f30386c78105cba520e443a6a9ee945ec1d066 ]

There exists the following warning when building bpftool:

  CC      prog.o
prog.c: In function ‘profile_open_perf_events’:
prog.c:2301:24: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 2301 |                 sizeof(int), obj->rodata->num_cpu * obj->rodata->num_metric);
      |                        ^~~
prog.c:2301:24: note: earlier argument should specify number of elements, later size of each element

Tested with the latest upstream GCC which contains a new warning option
-Wcalloc-transposed-args. The first argument to calloc is documented to
be number of elements in array, while the second argument is size of each
element, just switch the first and second arguments of calloc() to silence
the build warning, compile tested only.

Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command")
Signed-off-by: Tiezhu Yang 
Signed-off-by: Daniel Borkmann 
Reviewed-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20240116061920.31172-1-yangtiezhu@loongson.cn
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin

bpftool: Align output skeleton ELF code

2024-01-10T16:16:54+00:00

[ Upstream commit 23671f4dfd10b48b4a2fee4768886f0d8ec55b7e ]

libbpf accesses the ELF data requiring at least 8 byte alignment,
however, the data is generated into a C string that doesn't guarantee
alignment. Fix this by assigning to an aligned char array. Use sizeof
on the array, less one for the \0 terminator, rather than generating a
constant.

Fixes: a6cc6b34b93e ("bpftool: Provide a helper method for accessing skeleton's embedded ELF data")
Signed-off-by: Ian Rogers 
Signed-off-by: Andrii Nakryiko 
Reviewed-by: Alan Maguire 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20231007044439.25171-1-irogers@google.com
Signed-off-by: Sasha Levin

bpftool: Fix -Wcast-qual warning

2024-01-10T16:16:54+00:00

[ Upstream commit ebc8484d0e6da9e6c9e8cfa1f40bf94e9c6fc512 ]

This cast was made by purpose for older libbpf where the
bpf_object_skeleton field is void * instead of const void *
to eliminate a warning (as i understand
-Wincompatible-pointer-types-discards-qualifiers) but this
cast introduces another warning (-Wcast-qual) for libbpf
where data field is const void *

It makes sense for bpftool to be in sync with libbpf from
kernel sources

Signed-off-by: Denys Zagorui 
Signed-off-by: Andrii Nakryiko 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20230907090210.968612-1-dzagorui@cisco.com
Stable-dep-of: 23671f4dfd10 ("bpftool: Align output skeleton ELF code")
Signed-off-by: Sasha Levin

bpftool: Fix build warnings with -Wtype-limits

2023-08-30T06:39:00+00:00

Quentin reported build warnings when building bpftool :

    link.c: In function ‘perf_config_hw_cache_str’:
    link.c:86:18: warning: comparison of unsigned expression in ‘>= 0’ is always true [-Wtype-limits]
       86 |         if ((id) >= 0 && (id) < ARRAY_SIZE(array))      \
          |                  ^~
    link.c:320:20: note: in expansion of macro ‘perf_event_name’
      320 |         hw_cache = perf_event_name(evsel__hw_cache, config & 0xff);
          |                    ^~~~~~~~~~~~~~~
    [... more of the same for the other calls to perf_event_name ...]

He also pointed out the reason and the solution:

  We're always passing unsigned, so it should be safe to drop the check on
  (id) >= 0.

Fixes: 62b57e3ddd64 ("bpftool: Add perf event names")
Reported-by: Quentin Monnet 
Suggested-by: Quentin Monnet 
Signed-off-by: Yafang Shao 
Signed-off-by: Daniel Borkmann 
Acked-by: Quentin Monnet 
Closes: https://lore.kernel.org/bpf/a35d9a2d-54a0-49ec-9ed1-8fcf1369d3cc@isovalent.com
Link: https://lore.kernel.org/bpf/20230830030325.3786-1-laoar.shao@gmail.com

bpftool: Implement link show support for xdp

2023-08-16T17:14:17+00:00

Add support to dump XDP link information to bpftool. This reuses the
recently added show_link_ifindex_{plain,json}(). The XDP link info only
exposes the ifindex.

Below shows an example link dump output, and a cgroup link is included
for comparison, too:

  # bpftool link
  [...]
  10: cgroup  prog 2466
        cgroup_id 1  attach_type cgroup_inet6_post_bind
  [...]
  16: xdp  prog 2477
        ifindex enp5s0(3)
  [...]

Equivalent json output:

  # bpftool link --json
  [...]
  {
    "id": 10,
    "type": "cgroup",
    "prog_id": 2466,
    "cgroup_id": 1,
    "attach_type": "cgroup_inet6_post_bind"
  },
  [...]
  {
    "id": 16,
    "type": "xdp",
    "prog_id": 2477,
    "devname": "enp5s0",
    "ifindex": 3
  }
  [...]

Signed-off-by: Daniel Borkmann 
Reviewed-by: Quentin Monnet 
Link: https://lore.kernel.org/r/20230816095651.10014-2-daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau

bpftool: Implement link show support for tcx

2023-08-16T17:14:17+00:00

Add support to dump tcx link information to bpftool. This adds a
common helper show_link_ifindex_{plain,json}() which can be reused
also for other link types. The plain text and json device output is
the same format as in bpftool net dump.

Below shows an example link dump output along with a cgroup link
for comparison:

  # bpftool link
  [...]
  10: cgroup  prog 1977
        cgroup_id 1  attach_type cgroup_inet6_post_bind
  [...]
  13: tcx  prog 2053
        ifindex enp5s0(3)  attach_type tcx_ingress
  14: tcx  prog 2080
        ifindex enp5s0(3)  attach_type tcx_egress
  [...]

Equivalent json output:

  # bpftool link --json
  [...]
  {
    "id": 10,
    "type": "cgroup",
    "prog_id": 1977,
    "cgroup_id": 1,
    "attach_type": "cgroup_inet6_post_bind"
  },
  [...]
  {
    "id": 13,
    "type": "tcx",
    "prog_id": 2053,
    "devname": "enp5s0",
    "ifindex": 3,
    "attach_type": "tcx_ingress"
  },
  {
    "id": 14,
    "type": "tcx",
    "prog_id": 2080,
    "devname": "enp5s0",
    "ifindex": 3,
    "attach_type": "tcx_egress"
  }
  [...]

Suggested-by: Yafang Shao 
Signed-off-by: Daniel Borkmann 
Reviewed-by: Quentin Monnet 
Acked-by: Yafang Shao 
Link: https://lore.kernel.org/r/20230816095651.10014-1-daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau

bpftool: fix perf help message

2023-08-12T03:54:29+00:00

Currently, bpftool perf subcommand has typo with the help message.

    $ tools/bpf/bpftool/bpftool perf help
    Usage: bpftool perf { show | list }
           bpftool perf help }

Since this bpftool perf subcommand help message has the extra bracket,
this commit fix the typo by removing the extra bracket.

Signed-off-by: Daniel T. Lee 
Reviewed-by: Quentin Monnet 
Link: https://lore.kernel.org/r/20230811121603.17429-1-danieltimlee@gmail.com
Signed-off-by: Martin KaFai Lau

bpftool: Extend net dump with tcx progs

2023-07-19T17:07:28+00:00

Add support to dump fd-based attach types via bpftool. This includes both
the tc BPF link and attach ops programs. Dumped information contain the
attach location, function entry name, program ID and link ID when applicable.

Example with tc BPF link:

  # ./bpftool net
  xdp:

  tc:
  bond0(4) tcx/ingress cil_from_netdev prog_id 784 link_id 10
  bond0(4) tcx/egress cil_to_netdev prog_id 804 link_id 11

  flow_dissector:

  netfilter:

Example with tc BPF attach ops:

  # ./bpftool net
  xdp:

  tc:
  bond0(4) tcx/ingress cil_from_netdev prog_id 654
  bond0(4) tcx/egress cil_to_netdev prog_id 672

  flow_dissector:

  netfilter:

Currently, permanent flags are not yet supported, so 'unknown' ones are dumped
via NET_DUMP_UINT_ONLY() and once we do have permanent ones, we dump them as
human readable string.

Signed-off-by: Daniel Borkmann 
Reviewed-by: Quentin Monnet 
Link: https://lore.kernel.org/r/20230719140858.13224-7-daniel@iogearbox.net
Signed-off-by: Alexei Starovoitov