Commit Graph

12 Commits

Author SHA1 Message Date
Viktor Malik e9a1397683
bpftool: Enable libbpf logs when loading pid_iter in debug mode
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit be24a895149b6df4c474848e3928c237ad10fdc4
Author: Quentin Monnet <qmo@kernel.org>
Date:   Wed Mar 20 01:22:41 2024 +0000

    bpftool: Enable libbpf logs when loading pid_iter in debug mode
    
    When trying to load the pid_iter BPF program used to iterate over the
    PIDs of the processes holding file descriptors to BPF links, we would
    unconditionally silence libbpf in order to keep the output clean if the
    kernel does not support iterators and loading fails.
    
    Although this is the desirable behaviour in most cases, this may hide
    bugs in the pid_iter program that prevent it from loading, and it makes
    it hard to debug such load failures, even in "debug" mode. Instead, it
    makes more sense to print libbpf's logs when we pass the -d|--debug flag
    to bpftool, so that users get the logs to investigate failures without
    having to edit bpftool's source code.
    
    Signed-off-by: Quentin Monnet <qmo@kernel.org>
    Message-ID: <20240320012241.42991-1-qmo@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-07 13:58:32 +01:00
Jerome Marchand 24d396b55c libbpf: Hashmap interface update to allow both long and void* keys/values
Bugzilla: https://bugzilla.redhat.com/2177177

Conflicts: Some minor changes due to missing commits 09b73fe9e3de
("perf smt: Compute SMT from topology") and f0c4b97a2927 ("perf test:
Add basic core_wide expression test").

commit c302378bc157f6a73b6cae4ca67f5f6aa931dcec
Author: Eduard Zingerman <eddyz87@gmail.com>
Date:   Wed Nov 9 16:26:09 2022 +0200

    libbpf: Hashmap interface update to allow both long and void* keys/values

    An update for libbpf's hashmap interface from void* -> void* to a
    polymorphic one, allowing both long and void* keys and values.

    This simplifies many use cases in libbpf as hashmaps there are mostly
    integer to integer.

    Perf copies hashmap implementation from libbpf and has to be
    updated as well.

    Changes to libbpf, selftests/bpf and perf are packed as a single
    commit to avoid compilation issues with any future bisect.

    Polymorphic interface is acheived by hiding hashmap interface
    functions behind auxiliary macros that take care of necessary
    type casts, for example:

        #define hashmap_cast_ptr(p)                                         \
            ({                                                              \
                    _Static_assert((p) == NULL || sizeof(*(p)) == sizeof(long),\
                                   #p " pointee should be a long-sized integer or a pointer"); \
                    (long *)(p);                                            \
            })

        bool hashmap_find(const struct hashmap *map, long key, long *value);

        #define hashmap__find(map, key, value) \
                    hashmap_find((map), (long)(key), hashmap_cast_ptr(value))

    - hashmap__find macro casts key and value parameters to long
      and long* respectively
    - hashmap_cast_ptr ensures that value pointer points to a memory
      of appropriate size.

    This hack was suggested by Andrii Nakryiko in [1].
    This is a follow up for [2].

    [1] https://lore.kernel.org/bpf/CAEf4BzZ8KFneEJxFAaNCCFPGqp20hSpS2aCj76uRk3-qZUH5xg@mail.gmail.com/
    [2] https://lore.kernel.org/bpf/af1facf9-7bc8-8a3d-0db4-7b3f333589a2@meta.com/T/#m65b28f1d6d969fcd318b556db6a3ad499a42607d

    Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20221109142611.879983-2-eddyz87@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2023-04-28 11:43:02 +02:00
Jerome Marchand 89008b6063 bpftool: Add bpf_cookie to link output
Bugzilla: https://bugzilla.redhat.com/2120966

commit cbdaf71f7e65a45d6e96378ee7bfe3da39c30908
Author: Dmitrii Dolgov <9erthalion6@gmail.com>
Date:   Wed Mar 9 17:31:12 2022 +0100

    bpftool: Add bpf_cookie to link output

    Commit 82e6b1eee6a8 ("bpf: Allow to specify user-provided bpf_cookie for
    BPF perf links") introduced the concept of user specified bpf_cookie,
    which could be accessed by BPF programs using bpf_get_attach_cookie().
    For troubleshooting purposes it is convenient to expose bpf_cookie via
    bpftool as well, so there is no need to meddle with the target BPF
    program itself.

    Implemented using the pid iterator BPF program to actually fetch
    bpf_cookies, which allows constraining code changes only to bpftool.

    $ bpftool link
    1: type 7  prog 5
            bpf_cookie 123
            pids bootstrap(81)

    Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Yonghong Song <yhs@fb.com>
    Acked-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20220309163112.24141-1-9erthalion6@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2022-10-25 14:58:03 +02:00
Yauheni Kaliuta 11cec39963 bpftool: Fix error check when calling hashmap__new()
Bugzilla: http://bugzilla.redhat.com/2069045

commit 622a5b582cc27d3deedc38fcef68da2972e8e58d
Author: Mauricio Vásquez <mauricio@kinvolk.io>
Date:   Fri Jan 7 10:26:20 2022 -0500

    bpftool: Fix error check when calling hashmap__new()
    
    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 <mauricio@kinvolk.io>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Acked-by: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/bpf/20220107152620.192327-2-mauricio@kinvolk.io

Signed-off-by: Yauheni Kaliuta <ykaliuta@redhat.com>
2022-06-03 17:23:53 +03:00
Yauheni Kaliuta 765bcf6418 bpftool: Switch to libbpf's hashmap for PIDs/names references
Bugzilla: http://bugzilla.redhat.com/2069045

commit d6699f8e0f834b40db35466f704705ae757be11a
Author: Quentin Monnet <quentin@isovalent.com>
Date:   Sat Oct 23 21:51:54 2021 +0100

    bpftool: Switch to libbpf's hashmap for PIDs/names references
    
    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 <quentin@isovalent.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20211023205154.6710-6-quentin@isovalent.com

Signed-off-by: Yauheni Kaliuta <ykaliuta@redhat.com>
2022-06-03 17:23:46 +03:00
Andrii Nakryiko 932c605581 tools/bpftool: Fix PID fetching with a lot of results
In case of having so many PID results that they don't fit into a singe page
(4096) bytes, bpftool will erroneously conclude that it got corrupted data due
to 4096 not being a multiple of struct pid_iter_entry, so the last entry will
be partially truncated. Fix this by sizing the buffer to fit exactly N entries
with no truncation in the middle of record.

Fixes: d53dee3fe0 ("tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20201204232002.3589803-1-andrii@kernel.org
2020-12-08 16:45:20 +01:00
Yonghong Song 00fa1d83a8 bpftool: Handle EAGAIN error code properly in pids collection
When the error code is EAGAIN, the kernel signals the user
space should retry the read() operation for bpf iterators.
Let us do it.

Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200818222312.2181675-1-yhs@fb.com
2020-08-18 17:36:23 -07:00
Andrii Nakryiko 93776cb9ee tools/bpftool: Remove warning about PID iterator support
Don't emit warning that bpftool was built without PID iterator support. This
error garbles JSON output of otherwise perfectly valid show commands.

Reported-by: Andrey Ignatov <rdna@fb.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20200710232605.20918-1-andriin@fb.com
2020-07-13 15:41:05 -07:00
Louis Peens 625eb8e85e bpf: Fix another bpftool segfault without skeleton code enabled
emit_obj_refs_json needs to added the same as with emit_obj_refs_plain
to prevent segfaults, similar to Commit "8ae4121bd89e bpf: Fix bpftool
without skeleton code enabled"). See the error below:

    # ./bpftool -p prog
    {
        "error": "bpftool built without PID iterator support"
    },[{
            "id": 2,
            "type": "cgroup_skb",
            "tag": "7be49e3934a125ba",
            "gpl_compatible": true,
            "loaded_at": 1594052789,
            "uid": 0,
            "bytes_xlated": 296,
            "jited": true,
            "bytes_jited": 203,
            "bytes_memlock": 4096,
            "map_ids": [2,3
    Segmentation fault (core dumped)

The same happens for ./bpftool -p map, as well as ./bpftool -j prog/map.

Fixes: d53dee3fe0 ("tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs")
Signed-off-by: Louis Peens <louis.peens@netronome.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20200708110827.7673-1-louis.peens@netronome.com
2020-07-09 00:32:00 +02:00
John Fastabend 8ae4121bd8 bpf: Fix bpftool without skeleton code enabled
Fix segfault from bpftool by adding emit_obj_refs_plain when skeleton
code is disabled.

Tested by deleting BUILD_BPF_SKELS in Makefile. We found this doing
backports for Cilium when a testing image pulled in latest bpf-next
bpftool, but kept using an older clang-7.

  # ./bpftool prog show
  Error: bpftool built without PID iterator support
  3: cgroup_skb  tag 7be49e3934a125ba  gpl
          loaded_at 2020-07-01T08:01:29-0700  uid 0
  Segmentation fault

Fixes: d53dee3fe0 ("tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs")
Reported-by: Joe Stringer <joe@wand.net.nz>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/159375071997.14984.17404504293832961401.stgit@john-XPS-13-9370
2020-07-03 23:20:40 +02:00
Quentin Monnet 54b66c2255 tools, bpftool: Fix variable shadowing in emit_obj_refs_json()
Building bpftool yields the following complaint:

    pids.c: In function 'emit_obj_refs_json':
    pids.c:175:80: warning: declaration of 'json_wtr' shadows a global declaration [-Wshadow]
      175 | void emit_obj_refs_json(struct obj_refs_table *table, __u32 id, json_writer_t *json_wtr)
          |                                                                 ~~~~~~~~~~~~~~~^~~~~~~~
    In file included from pids.c:11:
    main.h:141:23: note: shadowed declaration is here
      141 | extern json_writer_t *json_wtr;
          |                       ^~~~~~~~

Let's rename the variable.

v2:
- Rename the variable instead of calling the global json_wtr directly.

Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200623213600.16643-1-quentin@isovalent.com
2020-06-24 15:46:28 +02:00
Andrii Nakryiko d53dee3fe0 tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs
Add bpf_iter-based way to find all the processes that hold open FDs against
BPF object (map, prog, link, btf). bpftool always attempts to discover this,
but will silently give up if kernel doesn't yet support bpf_iter BPF programs.
Process name and PID are emitted for each process (task group).

Sample output for each of 4 BPF objects:

$ sudo ./bpftool prog show
2694: cgroup_device  tag 8c42dee26e8cd4c2  gpl
        loaded_at 2020-06-16T15:34:32-0700  uid 0
        xlated 648B  jited 409B  memlock 4096B
        pids systemd(1)
2907: cgroup_skb  name egress  tag 9ad187367cf2b9e8  gpl
        loaded_at 2020-06-16T18:06:54-0700  uid 0
        xlated 48B  jited 59B  memlock 4096B  map_ids 2436
        btf_id 1202
        pids test_progs(2238417), test_progs(2238445)

$ sudo ./bpftool map show
2436: array  name test_cgr.bss  flags 0x400
        key 4B  value 8B  max_entries 1  memlock 8192B
        btf_id 1202
        pids test_progs(2238417), test_progs(2238445)
2445: array  name pid_iter.rodata  flags 0x480
        key 4B  value 4B  max_entries 1  memlock 8192B
        btf_id 1214  frozen
        pids bpftool(2239612)

$ sudo ./bpftool link show
61: cgroup  prog 2908
        cgroup_id 375301  attach_type egress
        pids test_progs(2238417), test_progs(2238445)
62: cgroup  prog 2908
        cgroup_id 375344  attach_type egress
        pids test_progs(2238417), test_progs(2238445)

$ sudo ./bpftool btf show
1202: size 1527B  prog_ids 2908,2907  map_ids 2436
        pids test_progs(2238417), test_progs(2238445)
1242: size 34684B
        pids bpftool(2258892)

Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20200619231703.738941-9-andriin@fb.com
2020-06-22 17:01:49 -07:00