Commit Graph

779 Commits

Author SHA1 Message Date
Jerome Marchand 4bc6786073 bpftool: Fix undefined behavior in qsort(NULL, 0, ...)
JIRA: https://issues.redhat.com/browse/RHEL-63880

commit f04e2ad394e2755d0bb2d858ecb5598718bf00d5
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date:   Tue Sep 10 23:02:07 2024 +0800

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

    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 <visitorckw@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Reviewed-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240910150207.3179306-1-visitorckw@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2025-01-21 11:27:04 +01:00
Jerome Marchand db37f3567b bpftool: Fix typos
JIRA: https://issues.redhat.com/browse/RHEL-63880

commit f028d7716cdeae3be7d8d211482248916b25b1c2
Author: Andrew Kreimer <algonell@gmail.com>
Date:   Mon Sep 9 12:24:41 2024 +0300

    bpftool: Fix typos

    Fix typos in documentation.

    Reported-by: Matthew Wilcox <willy@infradead.org>
    Reported-by: Quentin Monnet <qmo@kernel.org>
    Signed-off-by: Andrew Kreimer <algonell@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240909092452.4293-1-algonell@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2025-01-21 11:27:04 +01:00
Jerome Marchand 055a785e2f bpftool: Fix undefined behavior caused by shifting into the sign bit
JIRA: https://issues.redhat.com/browse/RHEL-63880

commit 4cdc0e4ce5e893bc92255f5f734d983012f2bc2e
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date:   Sun Sep 8 22:00:09 2024 +0800

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

    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 <visitorckw@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240908140009.3149781-1-visitorckw@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2025-01-21 11:27:04 +01:00
Jerome Marchand 57a23c9c54 bpftool: Improve btf c dump sorting stability
JIRA: https://issues.redhat.com/browse/RHEL-63880

commit f8c6b7913dfaa67475883f94261c278adbcaa0ae
Author: Mykyta Yatsenko <yatsenko@meta.com>
Date:   Fri Sep 6 14:24:53 2024 +0100

    bpftool: Improve btf c dump sorting stability

    Existing algorithm for BTF C dump sorting uses only types and names of
    the structs and unions for ordering. As dump contains structs with the
    same names but different contents, relative to each other ordering of
    those structs will be accidental.
    This patch addresses this problem by introducing a new sorting field
    that contains hash of the struct/union field names and types to
    disambiguate comparison of the non-unique named structs.

    Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20240906132453.146085-1-mykyta.yatsenko5@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2025-01-21 11:27:04 +01:00
Jerome Marchand 5d8f772596 bpftool: fix some typos in bpftool
JIRA: https://issues.redhat.com/browse/RHEL-63880

commit a86857d2546c98f6c4e5677af8c6b8a80edd0704
Author: Lin Yikai <yikai.lin@vivo.com>
Date:   Thu Sep 5 19:03:06 2024 +0800

    bpftool: fix some typos in bpftool

    Hi, fix some spelling errors in bpftool, the details are as follows:

    -in file "bpftool-gen.rst"
    	libppf->libbpf
    -in the code comments:
    	ouptut->output

    Signed-off-by: Lin Yikai <yikai.lin@vivo.com>
    Link: https://lore.kernel.org/r/20240905110354.3274546-2-yikai.lin@vivo.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2025-01-21 11:27:03 +01:00
Jerome Marchand 53de3c3030 tools/bpf: Fix the wrong format specifier
JIRA: https://issues.redhat.com/browse/RHEL-63880

commit 781f0bbbdade00f91490a3f64212e8cc8d75905c
Author: Zhu Jun <zhujun2@cmss.chinamobile.com>
Date:   Wed Jul 24 04:11:20 2024 -0700

    tools/bpf: Fix the wrong format specifier

    The format specifier of "unsigned int" in printf() should be "%u", not
    "%d".

    Signed-off-by: Zhu Jun <zhujun2@cmss.chinamobile.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240724111120.11625-1-zhujun2@cmss.chinamobile.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2025-01-13 17:36:36 +01:00
Viktor Malik 4f9a1b5557
bpftool: Fix handling enum64 in btf dump sorting
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit b0222d1d9e6f8551a056b89b0bff38f515f3c9b5
Author: Mykyta Yatsenko <yatsenko@meta.com>
Date:   Mon Sep 2 18:17:21 2024 +0100

    bpftool: Fix handling enum64 in btf dump sorting
    
    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 <yatsenko@meta.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240902171721.105253-1-mykyta.yatsenko5@gmail.com

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 15:55:20 +01:00
Viktor Malik ba90ab02d7
bpftool: Fix typo in usage help
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit 3c870059e9f8897c032f4256f90c41ee822218a8
Author: Donald Hunter <donald.hunter@gmail.com>
Date:   Wed Jul 17 14:45:08 2024 +0100

    bpftool: Fix typo in usage help
    
    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 <donald.hunter@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240717134508.77488-1-donald.hunter@gmail.com

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 15:55:18 +01:00
Viktor Malik 2dddaefcab
bpftool: improve skeleton backwards compat with old buggy libbpfs
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit 06e71ad534881d2a09ced7509d2ab0daedac4c96
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Mon Jul 8 13:45:38 2024 -0700

    bpftool: improve skeleton backwards compat with old buggy libbpfs
    
    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 <qmo@kernel.org>
    Co-developed-by: Mykyta Yatsenko <yatsenko@meta.com>
    Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Eduard Zingerman <eddyz87@gmail.com>
    Link: https://lore.kernel.org/r/20240708204540.4188946-2-andrii@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 15:55:16 +01:00
Viktor Malik fda5f71432
bpftool: Mount bpffs when pinmaps path not under the bpffs
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit da5f8fd1f0d393d5eaaba9ad8c22d1c26bb2bf9b
Author: Tao Chen <chen.dylane@gmail.com>
Date:   Tue Jul 2 21:11:50 2024 +0800

    bpftool: Mount bpffs when pinmaps path not under the bpffs
    
    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: 3767a94b32 ("bpftool: add pinmaps argument to the load/loadall")
    Signed-off-by: Tao Chen <chen.dylane@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Quentin Monnet <qmo@kernel.org>
    Reviewed-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240702131150.15622-1-chen.dylane@gmail.com

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 15:55:13 +01:00
Viktor Malik dd899215f4
bpftool: Allow compile-time checks of BPF map auto-attach support in skeleton
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit 651337c7ca82c259bf5c8fe9beda9673531a0031
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Tue Jun 18 11:38:32 2024 -0700

    bpftool: Allow compile-time checks of BPF map auto-attach support in skeleton
    
    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.<map> 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 <andrii@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240618183832.2535876-1-andrii@kernel.org

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 14:40:10 +01:00
Viktor Malik b1de25cdfe
bpftool: Support dumping kfunc prototypes from BTF
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit 770abbb5a25a5b767f1c60ba366aea503728e957
Author: Daniel Xu <dxu@dxuuu.xyz>
Date:   Wed Jun 12 09:58:36 2024 -0600

    bpftool: Support dumping kfunc prototypes from BTF
    
    This patch enables dumping kfunc prototypes from bpftool. This is useful
    b/c with this patch, end users will no longer have to manually define
    kfunc prototypes. For the kernel tree, this also means we can optionally
    drop kfunc prototypes from:
    
            tools/testing/selftests/bpf/bpf_kfuncs.h
            tools/testing/selftests/bpf/bpf_experimental.h
    
    Example usage:
    
            $ make PAHOLE=/home/dxu/dev/pahole/build/pahole -j30 vmlinux
    
            $ ./tools/bpf/bpftool/bpftool btf dump file ./vmlinux format c | rg "__ksym;" | head -3
            extern void cgroup_rstat_updated(struct cgroup *cgrp, int cpu) __weak __ksym;
            extern void cgroup_rstat_flush(struct cgroup *cgrp) __weak __ksym;
            extern struct bpf_key *bpf_lookup_user_key(u32 serial, u64 flags) __weak __ksym;
    
    Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
    Link: https://lore.kernel.org/r/bf6c08f9263c4bd9d10a717de95199d766a13f61.1718207789.git.dxu@dxuuu.xyz
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 14:40:07 +01:00
Viktor Malik d3abdcf41c
bpftool: Query only cgroup-related attach types
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit 98b303c9bf05dae932efbd71e18d81f6c64f20d8
Author: Kenta Tada <tadakentaso@gmail.com>
Date:   Fri Jun 7 20:17:04 2024 +0900

    bpftool: Query only cgroup-related attach types
    
    When CONFIG_NETKIT=y,
    bpftool-cgroup shows error even if the cgroup's path is correct:
    
    $ bpftool cgroup tree /sys/fs/cgroup
    CgroupPath
    ID       AttachType      AttachFlags     Name
    Error: can't query bpf programs attached to /sys/fs/cgroup: No such device or address
    
    >From strace and kernel tracing, I found netkit returned ENXIO and this command failed.
    I think this AttachType(BPF_NETKIT_PRIMARY) is not relevant to cgroup.
    
    bpftool-cgroup should query just only cgroup-related attach types.
    
    v2->v3:
      - removed an unnecessary check
    
    v1->v2:
      - used an array of cgroup attach types
    
    Signed-off-by: Kenta Tada <tadakentaso@gmail.com>
    Reviewed-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/r/20240607111704.6716-1-tadakentaso@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 14:40:06 +01:00
Viktor Malik 20a63f1df6
libbpf: Auto-attach struct_ops BPF maps in BPF skeleton
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit 08ac454e258e38813afb906650f19acce3afd982
Author: Mykyta Yatsenko <yatsenko@meta.com>
Date:   Wed Jun 5 18:51:35 2024 +0100

    libbpf: Auto-attach struct_ops BPF maps in BPF skeleton
    
    Similarly to `bpf_program`, support `bpf_map` automatic attachment in
    `bpf_object__attach_skeleton`. Currently only struct_ops maps could be
    attached.
    
    On bpftool side, code-generate links in skeleton struct for struct_ops maps.
    Similarly to `bpf_program_skeleton`, set links in `bpf_map_skeleton`.
    
    On libbpf side, extend `bpf_map` with new `autoattach` field to support
    enabling or disabling autoattach functionality, introducing
    getter/setter for this field.
    
    `bpf_object__(attach|detach)_skeleton` is extended with
    attaching/detaching struct_ops maps logic.
    
    Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20240605175135.117127-1-yatsenko@meta.com

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 14:40:05 +01:00
Viktor Malik dfe85d39d1
bpftool: Use BTF field iterator in btfgen
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit e1a8630291fde2a0edac2955e3df48587dac9906
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Tue Jun 4 17:16:28 2024 -0700

    bpftool: Use BTF field iterator in btfgen
    
    Switch bpftool's code which is using libbpf-internal
    btf_type_visit_type_ids() helper to new btf_field_iter functionality.
    
    This makes bpftool code simpler, but also unblocks removing libbpf's
    btf_type_visit_type_ids() helper completely.
    
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Alan Maguire <alan.maguire@oracle.com>
    Reviewed-by: Quentin Monnet <qmo@kernel.org>
    Acked-by: Eduard Zingerman <eddyz87@gmail.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Link: https://lore.kernel.org/bpf/20240605001629.4061937-5-andrii@kernel.org

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 14:40:05 +01:00
Viktor Malik 89ee07eb5a
bpftool: Fix typo in MAX_NUM_METRICS macro name
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit ce5249b91e34d81255c00950d415ebd4c3cae8d4
Author: Swan Beaujard <beaujardswan@gmail.com>
Date:   Mon Jun 3 00:58:12 2024 +0200

    bpftool: Fix typo in MAX_NUM_METRICS macro name
    
    Correct typo in bpftool profiler and change all instances of 'MATRICS' to
    'METRICS' in the profiler.bpf.c file.
    
    Signed-off-by: Swan Beaujard <beaujardswan@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240602225812.81171-1-beaujardswan@gmail.com

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 14:40:02 +01:00
Viktor Malik be40156d55
bpftool: Change pid_iter.bpf.c to comply with the change of bpf_link_fops.
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit d14c1fac0c9722c4ec79589921c9e798601ca9d5
Author: Kui-Feng Lee <thinker.li@gmail.com>
Date:   Wed May 29 23:59:46 2024 -0700

    bpftool: Change pid_iter.bpf.c to comply with the change of bpf_link_fops.
    
    To support epoll, a new instance of file_operations, bpf_link_fops_poll,
    has been added for links that support epoll. The pid_iter.bpf.c checks
    f_ops for links and other BPF objects. The check should fail for struct_ops
    links without this patch.
    
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Signed-off-by: Kui-Feng Lee <thinker.li@gmail.com>
    Link: https://lore.kernel.org/r/20240530065946.979330-9-thinker.li@gmail.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 14:40:01 +01:00
Viktor Malik 21bd1c32be bpftool: Un-const bpf_func_info to fix it for llvm 17 and newer
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit f4aba3471cfb9ccf69b476463f19b4c50fef6b14
Author: Ivan Babrou <ivan@cloudflare.com>
Date:   Mon May 20 15:51:49 2024 -0700

    bpftool: Un-const bpf_func_info to fix it for llvm 17 and newer
    
    LLVM 17 started treating const structs as constants:
    
    * https://github.com/llvm/llvm-project/commit/0b2d5b967d98
    
    Combined with pointer laundering via ptr_to_u64, which takes a const ptr,
    but in reality treats the underlying memory as mutable, this makes clang
    always pass zero to btf__type_by_id, which breaks full name resolution.
    
    Disassembly before (LLVM 16) and after (LLVM 17):
    
        -    8b 75 cc                 mov    -0x34(%rbp),%esi
        -    e8 47 8d 02 00           call   3f5b0 <btf__type_by_id>
        +    31 f6                    xor    %esi,%esi
        +    e8 a9 8c 02 00           call   3f510 <btf__type_by_id>
    
    It's a bigger project to fix this properly (and a question whether LLVM
    itself should detect this), but for right now let's just fix bpftool.
    
    For more information, see this thread in bpf mailing list:
    
    * https://lore.kernel.org/bpf/CABWYdi0ymezpYsQsPv7qzpx2fWuTkoD1-wG1eT-9x-TSREFrQg@mail.gmail.com/T/
    
    Fixes: b662000aff84 ("bpftool: Adding support for BTF program names")
    Signed-off-by: Ivan Babrou <ivan@cloudflare.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Nick Desaulniers <ndesaulniers@google.com>
    Acked-by: Yonghong Song <yonghong.song@linux.dev>
    Link: https://lore.kernel.org/bpf/20240520225149.5517-1-ivan@cloudflare.com

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 08:57:39 +01:00
Viktor Malik 4c6f518e3f bpftool: Introduce btf c dump sorting
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit 94133cf24bb33889aac267a7f0e3e6a08b8a8e5a
Author: Mykyta Yatsenko <yatsenko@meta.com>
Date:   Tue May 14 14:12:21 2024 +0100

    bpftool: Introduce btf c dump sorting
    
    Sort bpftool c dump output; aiming to simplify vmlinux.h diffing and
    forcing more natural type definitions ordering.
    
    Definitions are sorted first by their BTF kind ranks, then by their base
    type name and by their own name.
    
    Type ranks
    
    Assign ranks to btf kinds (defined in function btf_type_rank) to set
    next order:
    1. Anonymous enums/enums64
    2. Named enums/enums64
    3. Trivial types typedefs (ints, then floats)
    4. Structs/Unions
    5. Function prototypes
    6. Forward declarations
    
    Type rank is set to maximum for unnamed reference types, structs and
    unions to avoid emitting those types early. They will be emitted as
    part of the type chain starting with named type.
    
    Lexicographical ordering
    
    Each type is assigned a sort_name and own_name.
    sort_name is the resolved name of the final base type for reference
    types (typedef, pointer, array etc). Sorting by sort_name allows to
    group typedefs of the same base type. sort_name for non-reference type
    is the same as own_name. own_name is a direct name of particular type,
    is used as final sorting step.
    
    Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Tested-by: Andrii Nakryiko <andrii@kernel.org>
    Reviewed-by: Quentin Monnet <qmo@kernel.org>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20240514131221.20585-1-yatsenko@meta.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 08:57:39 +01:00
Viktor Malik 9eec25f8c7 bpftool: Fix make dependencies for vmlinux.h
JIRA: https://issues.redhat.com/browse/RHEL-30774

commit e7b64f9d3f5b10186038201e0b91f734cbd7fc3d
Author: Artem Savkov <asavkov@redhat.com>
Date:   Mon May 13 13:26:58 2024 +0200

    bpftool: Fix make dependencies for vmlinux.h
    
    With pre-generated vmlinux.h there is no dependency on neither vmlinux
    nor bootstrap bpftool. Define dependencies separately for both modes.
    This avoids needless rebuilds in some corner cases.
    
    Suggested-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Artem Savkov <asavkov@redhat.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240513112658.43691-1-asavkov@redhat.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-26 08:57:39 +01:00
Viktor Malik 120a9147d7
bpftool, selftests/hid/bpf: Fix 29 clang warnings
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit 41b307ad756e1b7b618bf9d9c1cce3595705ede4
Author: John Hubbard <jhubbard@nvidia.com>
Date:   Sun May 5 16:00:54 2024 -0700

    bpftool, selftests/hid/bpf: Fix 29 clang warnings
    
    When building either tools/bpf/bpftool, or tools/testing/selftests/hid,
    (the same Makefile is used for these), clang generates many instances of
    the following:
    
        "clang: warning: -lLLVM-17: 'linker' input unused"
    
    Quentin points out that the LLVM version is only required in $(LIBS),
    not in $(CFLAGS), so the fix is to remove it from CFLAGS.
    
    Suggested-by: Quentin Monnet <qmo@kernel.org>
    Signed-off-by: John Hubbard <jhubbard@nvidia.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240505230054.13813-1-jhubbard@nvidia.com

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-13 09:39:10 +01:00
Viktor Malik 057c37d840
bpftool: Address minor issues in bash completion
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit ad2d22b617b7c0ca2cff4da6dc063183822484bb
Author: Quentin Monnet <qmo@kernel.org>
Date:   Sat Apr 13 02:14:27 2024 +0100

    bpftool: Address minor issues in bash completion
    
    This commit contains a series of clean-ups and fixes for bpftool's bash
    completion file:
    
    - Make sure all local variables are declared as such.
    - Make sure variables are initialised before being read.
    - Update ELF section ("maps" -> ".maps") for looking up map names in
      object files.
    - Fix call to _init_completion.
    - Move definition for MAP_TYPE and PROG_TYPE higher up in the scope to
      avoid defining them multiple times, reuse MAP_TYPE where relevant.
    - Simplify completion for "duration" keyword in "bpftool prog profile".
    - Fix completion for "bpftool struct_ops register" and "bpftool link
      (pin|detach)" where we would repeatedly suggest file names instead of
      suggesting just one name.
    - Fix completion for "bpftool iter pin ... map MAP" to account for the
      "map" keyword.
    - Add missing "detach" suggestion for "bpftool link".
    
    Signed-off-by: Quentin Monnet <qmo@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240413011427.14402-3-qmo@kernel.org

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-11 07:44:47 +01:00
Viktor Malik 639423c852
bpftool: Update documentation where progs/maps can be passed by name
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit 986e7663f98ec7441d9d948263ec0dda71e7479f
Author: Quentin Monnet <qmo@kernel.org>
Date:   Sat Apr 13 02:14:26 2024 +0100

    bpftool: Update documentation where progs/maps can be passed by name
    
    When using references to BPF programs, bpftool supports passing programs
    by name on the command line. The manual pages for "bpftool prog" and
    "bpftool map" (for prog_array updates) mention it, but we have a few
    additional subcommands that support referencing programs by name but do
    not mention it in their documentation. Let's update the pages for
    subcommands "btf", "cgroup", and "net".
    
    Similarly, we can reference maps by name when passing them to "bpftool
    prog load", so we update the page for "bpftool prog" as well.
    
    Signed-off-by: Quentin Monnet <qmo@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240413011427.14402-2-qmo@kernel.org

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-11 07:44:47 +01:00
Viktor Malik db5c5c9760
bpftool: Fix typo in error message
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit 23cc4fe44f1df5ccce088a7c9398f96794047c2a
Author: Thorsten Blum <thorsten.blum@toblux.com>
Date:   Thu Apr 11 18:43:00 2024 +0200

    bpftool: Fix typo in error message
    
    s/at at/at a/
    
    Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/bpf/20240411164258.533063-3-thorsten.blum@toblux.com

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-11 07:44:46 +01:00
Viktor Malik 053ed0b95e
bpftool: Add link dump support for BPF_LINK_TYPE_SOCKMAP
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit 1f3e2091d25b2b140967480177fcaee2f0eebfb1
Author: Yonghong Song <yonghong.song@linux.dev>
Date:   Tue Apr 9 21:35:37 2024 -0700

    bpftool: Add link dump support for BPF_LINK_TYPE_SOCKMAP
    
    An example output looks like:
      $ bpftool link
        1776: sk_skb  prog 49730
                map_id 0  attach_type sk_skb_verdict
                pids test_progs(8424)
        1777: sk_skb  prog 49755
                map_id 0  attach_type sk_skb_stream_verdict
                pids test_progs(8424)
        1778: sk_msg  prog 49770
                map_id 8208  attach_type sk_msg_verdict
                pids test_progs(8424)
    
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Reviewed-by: Quentin Monnet <qmo@kernel.org>
    Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
    Link: https://lore.kernel.org/r/20240410043537.3737928-1-yonghong.song@linux.dev
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-07 14:37:17 +01:00
Viktor Malik a411de1c99
bpftool: Mount bpffs on provided dir instead of parent dir
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit 478a535ae54ad3831371904d93b5dfc403222e17
Author: Sahil Siddiq <icegambit91@gmail.com>
Date:   Fri Apr 5 00:52:19 2024 +0530

    bpftool: Mount bpffs on provided dir instead of parent dir
    
    When pinning programs/objects under PATH (eg: during "bpftool prog
    loadall") the bpffs is mounted on the parent dir of PATH in the
    following situations:
    - the given dir exists but it is not bpffs.
    - the given dir doesn't exist and the parent dir is not bpffs.
    
    Mounting on the parent dir can also have the unintentional side-
    effect of hiding other files located under the parent dir.
    
    If the given dir exists but is not bpffs, then the bpffs should
    be mounted on the given dir and not its parent dir.
    
    Similarly, if the given dir doesn't exist and its parent dir is not
    bpffs, then the given dir should be created and the bpffs should be
    mounted on this new dir.
    
    Fixes: 2a36c26fe3b8 ("bpftool: Support bpffs mountpoint as pin path for prog loadall")
    Signed-off-by: Sahil Siddiq <icegambit91@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/2da44d24-74ae-a564-1764-afccf395eeec@isovalent.com/T/#t
    Link: https://lore.kernel.org/bpf/20240404192219.52373-1-icegambit91@gmail.com
    
    Closes: https://github.com/libbpf/bpftool/issues/100
    
    Changes since v1:
     - Split "mount_bpffs_for_pin" into two functions.
       This is done to improve maintainability and readability.
    
    Changes since v2:
    - mount_bpffs_for_pin: rename to "create_and_mount_bpffs_dir".
    - mount_bpffs_given_file: rename to "mount_bpffs_given_file".
    - create_and_mount_bpffs_dir:
      - introduce "dir_exists" boolean.
      - remove new dir if "mnt_fs" fails.
    - improve error handling and error messages.
    
    Changes since v3:
    - Rectify function name.
    - Improve error messages and formatting.
    - mount_bpffs_for_file:
      - Check if dir exists before block_mount check.
    
    Changes since v4:
    - Use strdup instead of strcpy.
    - create_and_mount_bpffs_dir:
      - Use S_IRWXU instead of 0700.
    - Improve error handling and formatting.

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-07 13:58:44 +01:00
Viktor Malik 8083c3de39
bpftool: Use __typeof__() instead of typeof() in BPF skeleton
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit 2a24e2485722b0e12e17a2bd473bd15c9e420bdb
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Mon Apr 1 10:07:13 2024 -0700

    bpftool: Use __typeof__() instead of typeof() in BPF skeleton
    
    When generated BPF skeleton header is included in C++ code base, some
    compiler setups will emit warning about using language extensions due to
    typeof() usage, resulting in something like:
    
      error: extension used [-Werror,-Wlanguage-extension-token]
      obj->struct_ops.empty_tcp_ca = (typeof(obj->struct_ops.empty_tcp_ca))
                                      ^
    
    It looks like __typeof__() is a preferred way to do typeof() with better
    C++ compatibility behavior, so switch to that. With __typeof__() we get
    no such warning.
    
    Fixes: c2a0257c1edf ("bpftool: Cast pointers for shadow types explicitly.")
    Fixes: 00389c58ffe9 ("bpftool: Add support for subskeletons")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Kui-Feng Lee <thinker.li@gmail.com>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/20240401170713.2081368-1-andrii@kernel.org

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-07 13:58:41 +01:00
Viktor Malik 913befe6a8
bpftool: Clean-up typos, punctuation, list formatting in docs
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit a70f5d840a56a82c576385ca79ee55c1598f1bc3
Author: Rameez Rehman <rameezrehman408@hotmail.com>
Date:   Sun Mar 31 21:03:46 2024 +0100

    bpftool: Clean-up typos, punctuation, list formatting in docs
    
    Improve the formatting of the attach flags for cgroup programs in the
    relevant man page, and fix typos ("can be on of", "an userspace inet
    socket") when introducing that list. Also fix a couple of other trivial
    issues in docs.
    
    [ Quentin: Fixed trival issues in bpftool-gen.rst and bpftool-iter.rst ]
    
    Signed-off-by: Rameez Rehman <rameezrehman408@hotmail.com>
    Signed-off-by: Quentin Monnet <qmo@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240331200346.29118-4-qmo@kernel.org

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-07 13:58:40 +01:00
Viktor Malik 9f0dbfd825
bpftool: Remove useless emphasis on command description in man pages
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit ea379b3ccc2e4dff9c3d616f0611b5312fe389ad
Author: Rameez Rehman <rameezrehman408@hotmail.com>
Date:   Sun Mar 31 21:03:45 2024 +0100

    bpftool: Remove useless emphasis on command description in man pages
    
    As it turns out, the terms in definition lists in the rST file are
    already rendered with bold-ish formatting when generating the man pages;
    all double-star sequences we have in the commands for the command
    description are unnecessary, and can be removed to make the
    documentation easier to read.
    
    The rST files were automatically processed with:
    
        sed -i '/DESCRIPTION/,/OPTIONS/ { /^\*/ s/\*\*//g }' b*.rst
    
    Signed-off-by: Rameez Rehman <rameezrehman408@hotmail.com>
    Signed-off-by: Quentin Monnet <qmo@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240331200346.29118-3-qmo@kernel.org

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-07 13:58:39 +01:00
Viktor Malik 8cbd696b6d
bpftool: Use simpler indentation in source rST for documentation
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit f7b68543642136164ce7348945d3ada707c4e635
Author: Rameez Rehman <rameezrehman408@hotmail.com>
Date:   Sun Mar 31 21:03:44 2024 +0100

    bpftool: Use simpler indentation in source rST for documentation
    
    The rST manual pages for bpftool would use a mix of tabs and spaces for
    indentation. While this is the norm in C code, this is rather unusual
    for rST documents, and over time we've seen many contributors use a
    wrong level of indentation for documentation update.
    
    Let's fix bpftool's indentation in docs once and for all:
    
    - Let's use spaces, that are more common in rST files.
    - Remove one level of indentation for the synopsis, the command
      description, and the "see also" section. As a result, all sections
      start with the same indentation level in the generated man page.
    - Rewrap the paragraphs after the changes.
    
    There is no content change in this patch, only indentation and
    rewrapping changes. The wrapping in the generated source files for the
    manual pages is changed, but the pages displayed with "man" remain the
    same, apart from the adjusted indentation level on relevant sections.
    
    [ Quentin: rebased on bpf-next, removed indent level for command
      description and options, updated synopsis, command summary, and "see
      also" sections. ]
    
    Signed-off-by: Rameez Rehman <rameezrehman408@hotmail.com>
    Signed-off-by: Quentin Monnet <qmo@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240331200346.29118-2-qmo@kernel.org

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-07 13:58:39 +01:00
Viktor Malik 0a80c77e9c
bpftool: Clean up HOST_CFLAGS, HOST_LDFLAGS for bootstrap bpftool
JIRA: https://issues.redhat.com/browse/RHEL-30773

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

    bpftool: Clean up HOST_CFLAGS, HOST_LDFLAGS for bootstrap bpftool
    
    Bpftool's Makefile uses $(HOST_CFLAGS) to build the bootstrap version of
    bpftool, in order to pick the flags for the host (where we run the
    bootstrap version) and not for the target system (where we plan to run
    the full bpftool binary). But we pass too much information through this
    variable.
    
    In particular, we set HOST_CFLAGS by copying most of the $(CFLAGS); but
    we do this after the feature detection for bpftool, which means that
    $(CFLAGS), hence $(HOST_CFLAGS), contain all macro definitions for using
    the different optional features. For example, -DHAVE_LLVM_SUPPORT may be
    passed to the $(HOST_CFLAGS), even though the LLVM disassembler is not
    used in the bootstrap version, and the related library may even be
    missing for the host architecture.
    
    A similar thing happens with the $(LDFLAGS), that we use unchanged for
    linking the bootstrap version even though they may contains flags to
    link against additional libraries.
    
    To address the $(HOST_CFLAGS) issue, we move the definition of
    $(HOST_CFLAGS) earlier in the Makefile, before the $(CFLAGS) update
    resulting from the feature probing - none of which being relevant to the
    bootstrap version. To clean up the $(LDFLAGS) for the bootstrap version,
    we introduce a dedicated $(HOST_LDFLAGS) variable that we base on
    $(LDFLAGS), before the feature probing as well.
    
    On my setup, the following macro and libraries are removed from the
    compiler invocation to build bpftool after this patch:
    
      -DUSE_LIBCAP
      -DHAVE_LLVM_SUPPORT
      -I/usr/lib/llvm-17/include
      -D_GNU_SOURCE
      -D__STDC_CONSTANT_MACROS
      -D__STDC_FORMAT_MACROS
      -D__STDC_LIMIT_MACROS
      -lLLVM-17
      -L/usr/lib/llvm-17/lib
    
    Another advantage of cleaning up these flags is that displaying
    available features with "bpftool version" becomes more accurate for the
    bootstrap bpftool, and no longer reflects the features detected (and
    available only) for the final binary.
    
    Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>
    Signed-off-by: Quentin Monnet <qmo@kernel.org>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Message-ID: <20240320014103.45641-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:33 +01:00
Viktor Malik b724716ab6
bpftool: Remove unnecessary source files from bootstrap version
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit e9a826dd145bf2c19888aee1b974214cefc74a2e
Author: Quentin Monnet <qmo@kernel.org>
Date:   Wed Mar 20 01:34:57 2024 +0000

    bpftool: Remove unnecessary source files from bootstrap version
    
    Commit d510296d33 ("bpftool: Use syscall/loader program in "prog load"
    and "gen skeleton" command.") added new files to the list of objects to
    compile in order to build the bootstrap version of bpftool. As far as I
    can tell, these objects are unnecessary and were added by mistake; maybe
    a draft version intended to add support for loading loader programs from
    the bootstrap version. Anyway, we can remove these object files from the
    list to make the bootstrap bpftool binary a tad smaller and faster to
    build.
    
    Fixes: d510296d33 ("bpftool: Use syscall/loader program in "prog load" and "gen skeleton" command.")
    Signed-off-by: Quentin Monnet <qmo@kernel.org>
    Message-ID: <20240320013457.44808-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
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
Viktor Malik 0cf41d8a51
bpftool: Fix missing pids during link show
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit fe879bb42f8a6513ed18e9d22efb99cb35590201
Author: Yonghong Song <yonghong.song@linux.dev>
Date:   Mon Mar 11 19:32:49 2024 -0700

    bpftool: Fix missing pids during link show
    
    Current 'bpftool link' command does not show pids, e.g.,
      $ tools/build/bpftool/bpftool link
      ...
      4: tracing  prog 23
            prog_type lsm  attach_type lsm_mac
            target_obj_id 1  target_btf_id 31320
    
    Hack the following change to enable normal libbpf debug output,
      --- a/tools/bpf/bpftool/pids.c
      +++ b/tools/bpf/bpftool/pids.c
      @@ -121,9 +121,9 @@ int build_obj_refs_table(struct hashmap **map, enum bpf_obj_type type)
              /* we don't want output polluted with libbpf errors if bpf_iter is not
               * supported
               */
      -       default_print = libbpf_set_print(libbpf_print_none);
      +       /* default_print = libbpf_set_print(libbpf_print_none); */
              err = pid_iter_bpf__load(skel);
      -       libbpf_set_print(default_print);
      +       /* libbpf_set_print(default_print); */
    
    Rerun the above bpftool command:
      $ tools/build/bpftool/bpftool link
      libbpf: prog 'iter': BPF program load failed: Permission denied
      libbpf: prog 'iter': -- BEGIN PROG LOAD LOG --
      0: R1=ctx() R10=fp0
      ; struct task_struct *task = ctx->task; @ pid_iter.bpf.c:69
      0: (79) r6 = *(u64 *)(r1 +8)          ; R1=ctx() R6_w=ptr_or_null_task_struct(id=1)
      ; struct file *file = ctx->file; @ pid_iter.bpf.c:68
      ...
      ; struct bpf_link *link = (struct bpf_link *) file->private_data; @ pid_iter.bpf.c:103
      80: (79) r3 = *(u64 *)(r8 +432)       ; R3_w=scalar() R8=ptr_file()
      ; if (link->type == bpf_core_enum_value(enum bpf_link_type___local, @ pid_iter.bpf.c:105
      81: (61) r1 = *(u32 *)(r3 +12)
      R3 invalid mem access 'scalar'
      processed 39 insns (limit 1000000) max_states_per_insn 0 total_states 3 peak_states 3 mark_read 2
      -- END PROG LOAD LOG --
      libbpf: prog 'iter': failed to load: -13
      ...
    
    The 'file->private_data' returns a 'void' type and this caused subsequent 'link->type'
    (insn #81) failed in verification.
    
    To fix the issue, restore the previous BPF_CORE_READ so old kernels can also work.
    With this patch, the 'bpftool link' runs successfully with 'pids'.
      $ tools/build/bpftool/bpftool link
      ...
      4: tracing  prog 23
            prog_type lsm  attach_type lsm_mac
            target_obj_id 1  target_btf_id 31320
            pids systemd(1)
    
    Fixes: 44ba7b30e84f ("bpftool: Use a local copy of BPF_LINK_TYPE_PERF_EVENT in pid_iter.bpf.c")
    Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Tested-by: Quentin Monnet <quentin@isovalent.com>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20240312023249.3776718-1-yonghong.song@linux.dev

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-07 13:58:28 +01:00
Viktor Malik 0826582cff
bpftool: Cast pointers for shadow types explicitly.
JIRA: https://issues.redhat.com/browse/RHEL-30773

commit c2a0257c1edf16c6acd2afac7572d7e9043b6577
Author: Kui-Feng Lee <thinker.li@gmail.com>
Date:   Mon Mar 11 18:37:26 2024 -0700

    bpftool: Cast pointers for shadow types explicitly.
    
    According to a report, skeletons fail to assign shadow pointers when being
    compiled with C++ programs. Unlike C doing implicit casting for void
    pointers, C++ requires an explicit casting.
    
    To support C++, we do explicit casting for each shadow pointer.
    
    Also add struct_ops_module.skel.h to test_cpp to validate C++
    compilation as part of BPF selftests.
    
    Signed-off-by: Kui-Feng Lee <thinker.li@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Yonghong Song <yonghong.song@linux.dev>
    Acked-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20240312013726.1780720-1-thinker.li@gmail.com

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-11-07 13:58:25 +01:00
Jerome Marchand d53d19c2cd bpf: improve error message for unsupported helper
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit 786bf0e7e2ec90b349a7bab6e97947982ab31f2c
Author: Mykyta Yatsenko <yatsenko@meta.com>
Date:   Mon Mar 25 15:22:10 2024 +0000

    bpf: improve error message for unsupported helper

    BPF verifier emits "unknown func" message when given BPF program type
    does not support BPF helper. This message may be confusing for users, as
    important context that helper is unknown only to current program type is
    not provided.

    This patch changes message to "program of this type cannot use helper "
    and aligns dependent code in libbpf and tests. Any suggestions on
    improving/changing this message are welcome.

    Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Link: https://lore.kernel.org/r/20240325152210.377548-1-yatsenko@meta.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-17 11:07:07 +02:00
Jerome Marchand f24684ff64 libbpf, selftests/bpf: Adjust libbpf, bpftool, selftests to match LLVM
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit 10ebe835c937a11870690aa44c7c970fe906ff54
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Thu Mar 14 19:18:32 2024 -0700

    libbpf, selftests/bpf: Adjust libbpf, bpftool, selftests to match LLVM

    The selftests use
    to tell LLVM about special pointers. For LLVM there is nothing "arena"
    about them. They are simply pointers in a different address space.
    Hence LLVM diff https://github.com/llvm/llvm-project/pull/85161 renamed:
    . macro __BPF_FEATURE_ARENA_CAST -> __BPF_FEATURE_ADDR_SPACE_CAST
    . global variables in __attribute__((address_space(N))) are now
      placed in section named ".addr_space.N" instead of ".arena.N".

    Adjust libbpf, bpftool, and selftests to match LLVM.

    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/bpf/20240315021834.62988-3-alexei.starovoitov@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-15 10:49:16 +02:00
Jerome Marchand 044119b1e6 libbpf: Recognize __arena global variables.
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit 2e7ba4f8fd1fa879b37db0b738c23ba2af8292ee
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Thu Mar 7 17:08:08 2024 -0800

    libbpf: Recognize __arena global variables.

    LLVM automatically places __arena variables into ".arena.1" ELF section.
    In order to use such global variables bpf program must include definition
    of arena map in ".maps" section, like:
    struct {
           __uint(type, BPF_MAP_TYPE_ARENA);
           __uint(map_flags, BPF_F_MMAPABLE);
           __uint(max_entries, 1000);         /* number of pages */
           __ulong(map_extra, 2ull << 44);    /* start of mmap() region */
    } arena SEC(".maps");

    libbpf recognizes both uses of arena and creates single `struct bpf_map *`
    instance in libbpf APIs.
    ".arena.1" ELF section data is used as initial data image, which is exposed
    through skeleton and bpf_map__initial_value() to the user, if they need to tune
    it before the load phase. During load phase, this initial image is copied over
    into mmap()'ed region corresponding to arena, and discarded.

    Few small checks here and there had to be added to make sure this
    approach works with bpf_map__initial_value(), mostly due to hard-coded
    assumption that map->mmaped is set up with mmap() syscall and should be
    munmap()'ed. For arena, .arena.1 can be (much) smaller than maximum
    arena size, so this smaller data size has to be tracked separately.
    Given it is enforced that there is only one arena for entire bpf_object
    instance, we just keep it in a separate field. This can be generalized
    if necessary later.

    All global variables from ".arena.1" section are accessible from user space
    via skel->arena->name_of_var.

    For bss/data/rodata the skeleton/libbpf perform the following sequence:
    1. addr = mmap(MAP_ANONYMOUS)
    2. user space optionally modifies global vars
    3. map_fd = bpf_create_map()
    4. bpf_update_map_elem(map_fd, addr) // to store values into the kernel
    5. mmap(addr, MAP_FIXED, map_fd)
    after step 5 user spaces see the values it wrote at step 2 at the same addresses

    arena doesn't support update_map_elem. Hence skeleton/libbpf do:
    1. addr = malloc(sizeof SEC ".arena.1")
    2. user space optionally modifies global vars
    3. map_fd = bpf_create_map(MAP_TYPE_ARENA)
    4. real_addr = mmap(map->map_extra, MAP_SHARED | MAP_FIXED, map_fd)
    5. memcpy(real_addr, addr) // this will fault-in and allocate pages

    At the end look and feel of global data vs __arena global data is the same from
    bpf prog pov.

    Another complication is:
    struct {
      __uint(type, BPF_MAP_TYPE_ARENA);
    } arena SEC(".maps");

    int __arena foo;
    int bar;

      ptr1 = &foo;   // relocation against ".arena.1" section
      ptr2 = &arena; // relocation against ".maps" section
      ptr3 = &bar;   // relocation against ".bss" section

    Fo the kernel ptr1 and ptr2 has point to the same arena's map_fd
    while ptr3 points to a different global array's map_fd.
    For the verifier:
    ptr1->type == unknown_scalar
    ptr2->type == const_ptr_to_map
    ptr3->type == ptr_to_map_value

    After verification, from JIT pov all 3 ptr-s are normal ld_imm64 insns.

    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20240308010812.89848-11-alexei.starovoitov@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-15 10:49:15 +02:00
Jerome Marchand 7c3db7f3b3 bpftool: Recognize arena map type
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit eed512e8ac64339cfc69da1a6a4b60982cb502ca
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Thu Mar 7 17:08:07 2024 -0800

    bpftool: Recognize arena map type

    Teach bpftool to recognize arena map type.

    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20240308010812.89848-10-alexei.starovoitov@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-15 10:49:15 +02:00
Jerome Marchand 0d8850cd88 bpftool: rename is_internal_mmapable_map into is_mmapable_map
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit 1576b07961971d4eeb0e269c7133e9a6d430daf8
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Wed Mar 6 19:12:27 2024 -0800

    bpftool: rename is_internal_mmapable_map into is_mmapable_map

    It's not restricted to working with "internal" maps, it cares about any
    map that can be mmap'ed. Reflect that in more succinct and generic name.

    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/r/20240307031228.42896-6-alexei.starovoitov@gmail.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-15 10:49:14 +02:00
Jerome Marchand 1fbb5d2637 bpftool: Add an example for struct_ops map and shadow type.
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit f2e81192e07e87897ff1296c96775eceea8f582a
Author: Kui-Feng Lee <thinker.li@gmail.com>
Date:   Wed Feb 28 22:45:22 2024 -0800

    bpftool: Add an example for struct_ops map and shadow type.

    The example in bpftool-gen.8 explains how to use the pointer of the shadow
    type to change the value of a field of a struct_ops map.

    Signed-off-by: Kui-Feng Lee <thinker.li@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20240229064523.2091270-5-thinker.li@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-15 10:49:12 +02:00
Jerome Marchand 07405420ea bpftool: Generated shadow variables for struct_ops maps.
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit a7b0fa352eafef95bd0d736ca94965d3f884ad18
Author: Kui-Feng Lee <thinker.li@gmail.com>
Date:   Wed Feb 28 22:45:21 2024 -0800

    bpftool: Generated shadow variables for struct_ops maps.

    Declares and defines a pointer of the shadow type for each struct_ops map.

    The code generator will create an anonymous struct type as the shadow type
    for each struct_ops map. The shadow type is translated from the original
    struct type of the map. The user of the skeleton use pointers of them to
    access the values of struct_ops maps.

    However, shadow types only supports certain types of fields, including
    scalar types and function pointers. Any fields of unsupported types are
    translated into an array of characters to occupy the space of the original
    field. Function pointers are translated into pointers of the struct
    bpf_program. Additionally, padding fields are generated to occupy the space
    between two consecutive fields.

    The pointers of shadow types of struct_osp maps are initialized when
    *__open_opts() in skeletons are called. For a map called FOO, the user can
    access it through the pointer at skel->struct_ops.FOO.

    Signed-off-by: Kui-Feng Lee <thinker.li@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20240229064523.2091270-4-thinker.li@gmail.com

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-15 10:49:12 +02:00
Jerome Marchand 6fb45ecff2 bpftool: Be more portable by using POSIX's basename()
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit 29788f39a4171dd48a6d19eb78cf2ab168c4349a
Author: Arnaldo Carvalho de Melo <acme@kernel.org>
Date:   Mon Jan 29 11:33:26 2024 -0300

    bpftool: Be more portable by using POSIX's basename()

    musl libc had the basename() prototype in string.h, but this is a
    glibc-ism, now they removed the _GNU_SOURCE bits in their devel distro,
    Alpine Linux edge:

      https://git.musl-libc.org/cgit/musl/commit/?id=725e17ed6dff4d0cd22487bb64470881e86a92e7

    So lets use the POSIX version, the whole rationale is spelled out at:

      https://gitlab.alpinelinux.org/alpine/aports/-/issues/15643

    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Jiri Olsa <olsajiri@gmail.com>
    Acked-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/lkml/ZZhsPs00TI75RdAr@kernel.org
    Link: https://lore.kernel.org/bpf/Zbe3NuOgaupvUcpF@kernel.org

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-15 10:49:05 +02:00
Jerome Marchand aedd1d6308 bpftool: Display cookie for kprobe multi link
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit b0dc037399b19a777d569dbd9e2e9bbd62f3b3b1
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Fri Jan 19 12:05:05 2024 +0100

    bpftool: Display cookie for kprobe multi link

    Displaying cookies for kprobe multi link, in plain mode:

      # bpftool link
      ...
      1397: kprobe_multi  prog 47532
              kretprobe.multi  func_cnt 3
              addr             cookie           func [module]
              ffffffff82b370c0 3                bpf_fentry_test1
              ffffffff82b39780 1                bpf_fentry_test2
              ffffffff82b397a0 2                bpf_fentry_test3

    And in json mode:

      # bpftool link -j | jq
      ...
        {
          "id": 1397,
          "type": "kprobe_multi",
          "prog_id": 47532,
          "retprobe": true,
          "func_cnt": 3,
          "missed": 0,
          "funcs": [
            {
              "addr": 18446744071607382208,
              "func": "bpf_fentry_test1",
              "module": null,
              "cookie": 3
            },
            {
              "addr": 18446744071607392128,
              "func": "bpf_fentry_test2",
              "module": null,
              "cookie": 1
            },
            {
              "addr": 18446744071607392160,
              "func": "bpf_fentry_test3",
              "module": null,
              "cookie": 2
            }
          ]
        }

    Cookie is attached to specific address, and because we sort addresses
    before printing, we need to sort cookies the same way, hence adding
    the struct addr_cookie to keep and sort them together.

    Also adding missing dd.sym_count check to show_kprobe_multi_json.

    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Acked-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240119110505.400573-9-jolsa@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-15 10:49:01 +02:00
Jerome Marchand 7ff4fc3e12 bpftool: Display cookie for perf event link probes
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit 54258324b934aa8552c239c443272ec7aea55285
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Fri Jan 19 12:05:04 2024 +0100

    bpftool: Display cookie for perf event link probes

    Displaying cookie for perf event link probes, in plain mode:

      # bpftool link
      17: perf_event  prog 90
              kprobe ffffffff82b1c2b0 bpf_fentry_test1  cookie 3735928559
      18: perf_event  prog 90
              kretprobe ffffffff82b1c2b0 bpf_fentry_test1  cookie 3735928559
      20: perf_event  prog 92
              tracepoint sched_switch  cookie 3735928559
      21: perf_event  prog 93
              event software:page-faults  cookie 3735928559
      22: perf_event  prog 91
              uprobe /proc/self/exe+0xd703c  cookie 3735928559

    And in json mode:

      # bpftool link -j | jq

      {
        "id": 30,
        "type": "perf_event",
        "prog_id": 160,
        "retprobe": false,
        "addr": 18446744071607272112,
        "func": "bpf_fentry_test1",
        "offset": 0,
        "missed": 0,
        "cookie": 3735928559
      }

      {
        "id": 33,
        "type": "perf_event",
        "prog_id": 162,
        "tracepoint": "sched_switch",
        "cookie": 3735928559
      }

      {
        "id": 34,
        "type": "perf_event",
        "prog_id": 163,
        "event_type": "software",
        "event_config": "page-faults",
        "cookie": 3735928559
      }

      {
        "id": 35,
        "type": "perf_event",
        "prog_id": 161,
        "retprobe": false,
        "file": "/proc/self/exe",
        "offset": 880700,
        "cookie": 3735928559
      }

    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Acked-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240119110505.400573-8-jolsa@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-15 10:49:01 +02:00
Jerome Marchand 8f01f03e4f bpftool: Silence build warning about calloc()
JIRA: https://issues.redhat.com/browse/RHEL-23649

commit f5f30386c78105cba520e443a6a9ee945ec1d066
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Tue Jan 16 14:19:20 2024 +0800

    bpftool: Silence build warning about calloc()

    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: 47c09d6a9f ("bpftool: Introduce "prog profile" command")
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20240116061920.31172-1-yangtiezhu@loongson.cn
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
2024-10-15 10:49:00 +02:00
Viktor Malik e5ee401c4d
bpftool: Fix wrong free call in do_show_link
JIRA: https://issues.redhat.com/browse/RHEL-23644

commit 2adb2e0fcdf3c6d8e28a5a9c33e458e1037ae5ad
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Fri Jan 19 12:05:00 2024 +0100

    bpftool: Fix wrong free call in do_show_link
    
    The error path frees wrong array, it should be ref_ctr_offsets.
    
    Acked-by: Yafang Shao <laoar.shao@gmail.com>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Fixes: a7795698f8b6 ("bpftool: Add support to display uprobe_multi links")
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Acked-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240119110505.400573-4-jolsa@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-06-25 11:07:43 +02:00
Viktor Malik 62bad0391f
bpftool: Add support to display uprobe_multi links
JIRA: https://issues.redhat.com/browse/RHEL-23644

commit a7795698f8b6c48283fa4334eb313bc1350b2864
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Sat Nov 25 20:31:30 2023 +0100

    bpftool: Add support to display uprobe_multi links
    
    Adding support to display details for uprobe_multi links,
    both plain:
    
      # bpftool link -p
      ...
      24: uprobe_multi  prog 126
              uprobe.multi  path /home/jolsa/bpf/test_progs  func_cnt 3  pid 4143
              offset             ref_ctr_offset     cookies
              0xd1f88            0xf5d5a8           0xdead
              0xd1f8f            0xf5d5aa           0xbeef
              0xd1f96            0xf5d5ac           0xcafe
    
    and json:
    
      # bpftool link -p
      [{
      ...
          },{
              "id": 24,
              "type": "uprobe_multi",
              "prog_id": 126,
              "retprobe": false,
              "path": "/home/jolsa/bpf/test_progs",
              "func_cnt": 3,
              "pid": 4143,
              "funcs": [{
                      "offset": 860040,
                      "ref_ctr_offset": 16111016,
                      "cookie": 57005
                  },{
                      "offset": 860047,
                      "ref_ctr_offset": 16111018,
                      "cookie": 48879
                  },{
                      "offset": 860054,
                      "ref_ctr_offset": 16111020,
                      "cookie": 51966
                  }
              ]
          }
      ]
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Acked-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/bpf/20231125193130.834322-7-jolsa@kernel.org

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-06-25 10:51:59 +02:00
Viktor Malik 8564f3863c
bpftool: mark orphaned programs during prog show
JIRA: https://issues.redhat.com/browse/RHEL-23644

commit 876843ce1e4897e8ceade50bfa3d9a4ec483abf3
Author: Stanislav Fomichev <sdf@google.com>
Date:   Mon Nov 27 10:20:56 2023 -0800

    bpftool: mark orphaned programs during prog show
    
    Commit ef01f4e25c17 ("bpf: restore the ebpf program ID for BPF_AUDIT_UNLOAD
    and PERF_BPF_EVENT_PROG_UNLOAD") stopped removing program's id from
    idr when the offloaded/bound netdev goes away. I was supposed to
    take a look and check in [0], but apparently I did not.
    
    Martin points out it might be useful to keep it that way for
    observability sake, but we at least need to mark those programs as
    unusable.
    
    Mark those programs as 'orphaned' and keep printing the list when
    we encounter ENODEV.
    
    0: unspec  tag 0000000000000000
            xlated 0B  not jited  memlock 4096B  orphaned
    
    [0]: https://lore.kernel.org/all/CAKH8qBtyR20ZWAc11z1-6pGb3Hd47AQUTbE_cfoktG59TqaJ7Q@mail.gmail.com/
    
    v3:
    * use two spaces for "  orphaned" (Quentin)
    
    Cc: netdev@vger.kernel.org
    Fixes: ef01f4e25c17 ("bpf: restore the ebpf program ID for BPF_AUDIT_UNLOAD and PERF_BPF_EVENT_PROG_UNLOAD")
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/r/20231127182057.1081138-1-sdf@google.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-06-25 10:51:57 +02:00
Viktor Malik 19e9f3055f
bpftool: Fix prog object type in manpage
JIRA: https://issues.redhat.com/browse/RHEL-23644

commit a46afaa03f6db8c65492302ffdafcb2e769e5667
Author: Artem Savkov <asavkov@redhat.com>
Date:   Fri Nov 3 09:11:26 2023 +0100

    bpftool: Fix prog object type in manpage
    
    bpftool's man page lists "program" as one of possible values for OBJECT,
    while in fact bpftool accepts "prog" instead.
    
    Reported-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Signed-off-by: Artem Savkov <asavkov@redhat.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Yonghong Song <yonghong.song@linux.dev>
    Acked-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20231103081126.170034-1-asavkov@redhat.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Signed-off-by: Viktor Malik <vmalik@redhat.com>
2024-06-25 10:51:39 +02:00