17 Jan, 2021

1 commit

  • commit 6f02b540d7597f357bc6ee711346761045d4e108 upstream.

    For older glibc ~2.17, #include'ing both linux/if.h and net/if.h
    fails due to complaints about redefinition of interface flags:

    CC net.o
    In file included from net.c:13:0:
    /usr/include/linux/if.h:71:2: error: redeclaration of enumerator ‘IFF_UP’
    IFF_UP = 1< resolves the issue and it is
    not needed for compilation anyhow.

    [1] https://lore.kernel.org/netdev/1461512707-23058-1-git-send-email-mikko.rapeli__34748.27880641$1462831734$gmane$org@iki.fi/

    Fixes: f6f3bac08ff9 ("tools/bpf: bpftool: add net support")
    Signed-off-by: Alan Maguire
    Signed-off-by: Andrii Nakryiko
    Acked-by: Martin KaFai Lau
    Link: https://lore.kernel.org/bpf/1609948746-15369-1-git-send-email-alan.maguire@oracle.com
    Signed-off-by: Greg Kroah-Hartman

    Alan Maguire
     

08 Dec, 2020

1 commit

  • 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: d53dee3fe013 ("tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs")
    Signed-off-by: Andrii Nakryiko
    Signed-off-by: Daniel Borkmann
    Acked-by: Yonghong Song
    Link: https://lore.kernel.org/bpf/20201204232002.3589803-1-andrii@kernel.org

    Andrii Nakryiko
     

25 Nov, 2020

1 commit

  • An appropriate return value should be set on the failed path.

    Fixes: 4d374ba0bf30 ("tools: bpftool: implement "bpftool btf show|list"")
    Reported-by: Hulk Robot
    Signed-off-by: Zhen Lei
    Signed-off-by: Daniel Borkmann
    Acked-by: Yonghong Song
    Link: https://lore.kernel.org/bpf/20201124104100.491-1-thunder.leizhen@huawei.com

    Zhen Lei
     

13 Nov, 2020

1 commit

  • progfd is created by prog_parse_fd() in do_attach() and before the latter
    returns in case of success, the file descriptor should be closed.

    Fixes: 04949ccc273e ("tools: bpftool: add net attach command to attach XDP on interface")
    Signed-off-by: Wang Hai
    Signed-off-by: Daniel Borkmann
    Link: https://lore.kernel.org/bpf/20201113115152.53178-1-wanghai38@huawei.com

    Wang Hai
     

06 Nov, 2020

1 commit

  • My earlier patch to reject non-zero arguments to flow dissector attach
    broke attaching via bpftool. Instead of 0 it uses -1 for target_fd.
    Fix this by passing a zero argument when attaching the flow dissector.

    Fixes: 1b514239e859 ("bpf: flow_dissector: Check value of unused flags to BPF_PROG_ATTACH")
    Reported-by: Jiri Benc
    Signed-off-by: Lorenz Bauer
    Signed-off-by: Alexei Starovoitov
    Acked-by: Song Liu
    Link: https://lore.kernel.org/bpf/20201105115230.296657-1-lmb@cloudflare.com

    Lorenz Bauer
     

29 Oct, 2020

2 commits

  • Avoid an unused variable warning.

    Signed-off-by: Ian Rogers
    Signed-off-by: Daniel Borkmann
    Reviewed-by: Tobias Klauser
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20201027233646.3434896-2-irogers@google.com

    Ian Rogers
     
  • The bpf_caps array is shorter without CAP_BPF, avoid out of bounds reads
    if this isn't defined. Working around this avoids -Wno-array-bounds with
    clang.

    Signed-off-by: Ian Rogers
    Signed-off-by: Daniel Borkmann
    Reviewed-by: Tobias Klauser
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20201027233646.3434896-1-irogers@google.com

    Ian Rogers
     

06 Oct, 2020

1 commit


19 Sep, 2020

1 commit

  • This change facilitates out-of-tree builds, packaging, and versioning for
    test and debug purposes. Defining BPFTOOL_VERSION allows self-contained
    builds within the tools tree, since it avoids use of the 'kernelversion'
    target in the top-level makefile, which would otherwise pull in several
    other includes from outside the tools tree.

    Signed-off-by: Tony Ambardar
    Signed-off-by: Daniel Borkmann
    Acked-by: Quentin Monnet
    Acked-by: Song Liu
    Link: https://lore.kernel.org/bpf/20200917115833.1235518-1-Tony.Ambardar@gmail.com

    Tony Ambardar
     

16 Sep, 2020

1 commit

  • Dump metadata in the 'bpftool prog' list if it's present.
    For some formatting some BTF code is put directly in the
    metadata dumping. Sanity checks on the map and the kind of the btf_type
    to make sure we are actually dumping what we are expecting.

    A helper jsonw_reset is added to json writer so we can reuse the same
    json writer without having extraneous commas.

    Sample output:

    $ bpftool prog
    6: cgroup_skb name prog tag bcf7977d3b93787c gpl
    [...]
    btf_id 4
    metadata:
    a = "foo"
    b = 1

    $ bpftool prog --json --pretty
    [{
    "id": 6,
    [...]
    "btf_id": 4,
    "metadata": {
    "a": "foo",
    "b": 1
    }
    }
    ]

    Signed-off-by: YiFei Zhu
    Signed-off-by: Stanislav Fomichev
    Signed-off-by: Alexei Starovoitov
    Cc: YiFei Zhu
    Link: https://lore.kernel.org/bpf/20200915234543.3220146-5-sdf@google.com

    YiFei Zhu
     

15 Sep, 2020

1 commit

  • When building bpf selftests like
    make -C tools/testing/selftests/bpf -j20
    I hit the following errors:
    ...
    GEN /net-next/tools/testing/selftests/bpf/tools/build/bpftool/Documentation/bpftool-gen.8
    :75: (WARNING/2) Block quote ends without a blank line; unexpected unindent.
    :71: (WARNING/2) Literal block ends without a blank line; unexpected unindent.
    :85: (WARNING/2) Literal block ends without a blank line; unexpected unindent.
    :57: (WARNING/2) Block quote ends without a blank line; unexpected unindent.
    :66: (WARNING/2) Literal block ends without a blank line; unexpected unindent.
    :109: (WARNING/2) Literal block ends without a blank line; unexpected unindent.
    :175: (WARNING/2) Literal block ends without a blank line; unexpected unindent.
    :273: (WARNING/2) Literal block ends without a blank line; unexpected unindent.
    make[1]: *** [/net-next/tools/testing/selftests/bpf/tools/build/bpftool/Documentation/bpftool-perf.8] Error 12
    make[1]: *** Waiting for unfinished jobs....
    make[1]: *** [/net-next/tools/testing/selftests/bpf/tools/build/bpftool/Documentation/bpftool-iter.8] Error 12
    make[1]: *** [/net-next/tools/testing/selftests/bpf/tools/build/bpftool/Documentation/bpftool-struct_ops.8] Error 12
    ...

    I am using:
    -bash-4.4$ rst2man --version
    rst2man (Docutils 0.11 [repository], Python 2.7.5, on linux2)
    -bash-4.4$

    The Makefile generated final .rst file (e.g., bpftool-cgroup.rst) looks like
    ...
    ID AttachType AttachFlags Name
    \n SEE ALSO\n========\n\t**bpf**\ (2),\n\t**bpf-helpers**\
    (7),\n\t**bpftool**\ (8),\n\t**bpftool-btf**\
    (8),\n\t**bpftool-feature**\ (8),\n\t**bpftool-gen**\
    (8),\n\t**bpftool-iter**\ (8),\n\t**bpftool-link**\
    (8),\n\t**bpftool-map**\ (8),\n\t**bpftool-net**\
    (8),\n\t**bpftool-perf**\ (8),\n\t**bpftool-prog**\
    (8),\n\t**bpftool-struct_ops**\ (8)\n

    The rst2man generated .8 file looks like
    Literal block ends without a blank line; unexpected unindent.
    .sp
    n SEEALSOn========nt**bpf**(2),nt**bpf\-helpers**(7),nt**bpftool**(8),nt**bpftool\-btf**(8),nt**
    bpftool\-feature**(8),nt**bpftool\-gen**(8),nt**bpftool\-iter**(8),nt**bpftool\-link**(8),nt**
    bpftool\-map**(8),nt**bpftool\-net**(8),nt**bpftool\-perf**(8),nt**bpftool\-prog**(8),nt**
    bpftool\-struct_ops**(8)n

    Looks like that particular version of rst2man prefers to have actual new line
    instead of \n.

    Since `echo -e` may not be available in some environment, let us use `printf`.
    Format string "%b" is used for `printf` to ensure all escape characters are
    interpretted properly.

    Fixes: 18841da98100 ("tools: bpftool: Automate generation for "SEE ALSO" sections in man pages")
    Suggested-by: Andrii Nakryiko
    Signed-off-by: Yonghong Song
    Signed-off-by: Alexei Starovoitov
    Acked-by: Song Liu
    Acked-by: Andrii Nakryiko
    Cc: Quentin Monnet
    Link: https://lore.kernel.org/bpf/20200914183110.999906-1-yhs@fb.com

    Yonghong Song
     

11 Sep, 2020

7 commits

  • The "SEE ALSO" sections of bpftool's manual pages refer to bpf(2),
    bpf-helpers(7), then all existing bpftool man pages (save the current
    one).

    This leads to nearly-identical lists being duplicated in all manual
    pages. Ideally, when a new page is created, all lists should be updated
    accordingly, but this has led to omissions and inconsistencies multiple
    times in the past.

    Let's take it out of the RST files and generate the "SEE ALSO" sections
    automatically in the Makefile when generating the man pages. The lists
    are not really useful in the RST anyway because all other pages are
    available in the same directory.

    v3:
    - Fix conflict with a previous patchset that introduced RST2MAN_OPTS
    variable passed to rst2man.

    v2:
    - Use "echo -n" instead of "printf" in Makefile, to avoid any risk of
    passing a format string directly to the command.

    Signed-off-by: Quentin Monnet
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20200910203935.25304-1-quentin@isovalent.com

    Quentin Monnet
     
  • There is no support for creating maps of types array-of-map or
    hash-of-map in bpftool. This is because the kernel needs an inner_map_fd
    to collect metadata on the inner maps to be supported by the new map,
    but bpftool does not provide a way to pass this file descriptor.

    Add a new optional "inner_map" keyword that can be used to pass a
    reference to a map, retrieve a fd to that map, and pass it as the
    inner_map_fd.

    Add related documentation and bash completion. Note that we can
    reference the inner map by its name, meaning we can have several times
    the keyword "name" with different meanings (mandatory outer map name,
    and possibly a name to use to find the inner_map_fd). The bash
    completion will offer it just once, and will not suggest "name" on the
    following command:

    # bpftool map create /sys/fs/bpf/my_outer_map type hash_of_maps \
    inner_map name my_inner_map [TAB]

    Fixing that specific case seems too convoluted. Completion will work as
    expected, however, if the outer map name comes first and the "inner_map
    name ..." is passed second.

    Signed-off-by: Quentin Monnet
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20200910102652.10509-4-quentin@isovalent.com

    Quentin Monnet
     
  • When dumping outer maps or prog_array maps, and on lookup failure,
    bpftool simply skips the entry with no error message. This is because
    the kernel returns non-zero when no value is found for the provided key,
    which frequently happen for those maps if they have not been filled.

    When such a case occurs, errno is set to ENOENT. It seems unlikely we
    could receive other error codes at this stage (we successfully retrieved
    map info just before), but to be on the safe side, let's skip the entry
    only if errno was ENOENT, and not for the other errors.

    v3: New patch

    Signed-off-by: Quentin Monnet
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20200910102652.10509-3-quentin@isovalent.com

    Quentin Monnet
     
  • The function used to dump a map entry in bpftool is a bit difficult to
    follow, as a consequence to earlier refactorings. There is a variable
    ("num_elems") which does not appear to be necessary, and the error
    handling would look cleaner if moved to its own function. Let's clean it
    up. No functional change.

    v2:
    - v1 was erroneously removing the check on fd maps in an attempt to get
    support for outer map dumps. This is already working. Instead, v2
    focuses on cleaning up the dump_map_elem() function, to avoid
    similar confusion in the future.

    Signed-off-by: Quentin Monnet
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20200910102652.10509-2-quentin@isovalent.com

    Quentin Monnet
     
  • Nearly all man pages for bpftool have the same common set of option
    flags (--help, --version, --json, --pretty, --debug). The description is
    duplicated across all the pages, which is more difficult to maintain if
    the description of an option changes. It may also be confusing to sort
    out what options are not "common" and should not be copied when creating
    new manual pages.

    Let's move the description for those common options to a separate file,
    which is included with a RST directive when generating the man pages.

    Signed-off-by: Quentin Monnet
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20200909162500.17010-3-quentin@isovalent.com

    Quentin Monnet
     
  • Bpftool has a number of features that can be included or left aside
    during compilation. This includes:

    - Support for libbfd, providing the disassembler for JIT-compiled
    programs.
    - Support for BPF skeletons, used for profiling programs or iterating on
    the PIDs of processes associated with BPF objects.

    In order to make it easy for users to understand what features were
    compiled for a given bpftool binary, print the status of the two
    features above when showing the version number for bpftool ("bpftool -V"
    or "bpftool version"). Document this in the main manual page. Example
    invocations:

    $ bpftool version
    ./bpftool v5.9.0-rc1
    features: libbfd, skeletons

    $ bpftool -p version
    {
    "version": "5.9.0-rc1",
    "features": {
    "libbfd": true,
    "skeletons": true
    }
    }

    Some other parameters are optional at compilation
    ("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
    significantly bpftool's behaviour from a user's point of view, so their
    status is not reported.

    Available commands and supported program types depend on the version
    number, and are therefore not reported either. Note that they are
    already available, albeit without JSON, via bpftool's help messages.

    v3:
    - Use a simple list instead of boolean values for plain output.

    v2:
    - Fix JSON (object instead or array for the features).

    Signed-off-by: Quentin Monnet
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com

    Quentin Monnet
     
  • To build man pages for bpftool (and for eBPF helper functions), rst2man
    can log different levels of information. Let's make it log all levels
    to keep the RST files clean.

    Doing so, rst2man complains about double colons, used for literal
    blocks, that look like underlines for section titles. Let's add the
    necessary blank lines.

    v2:
    - Use "--verbose" instead of "-r 1" (same behaviour but more readable).
    - Pass it through a RST2MAN_OPTS variable so we can easily pass other
    options too.

    Signed-off-by: Quentin Monnet
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20200909162251.15498-2-quentin@isovalent.com

    Quentin Monnet
     

07 Sep, 2020

1 commit


04 Sep, 2020

1 commit


02 Sep, 2020

1 commit

  • Daniel Borkmann says:

    ====================
    pull-request: bpf-next 2020-09-01

    The following pull-request contains BPF updates for your *net-next* tree.

    There are two small conflicts when pulling, resolve as follows:

    1) Merge conflict in tools/lib/bpf/libbpf.c between 88a82120282b ("libbpf: Factor
    out common ELF operations and improve logging") in bpf-next and 1e891e513e16
    ("libbpf: Fix map index used in error message") in net-next. Resolve by taking
    the hunk in bpf-next:

    [...]
    scn = elf_sec_by_idx(obj, obj->efile.btf_maps_shndx);
    data = elf_sec_data(obj, scn);
    if (!scn || !data) {
    pr_warn("elf: failed to get %s map definitions for %s\n",
    MAPS_ELF_SEC, obj->path);
    return -EINVAL;
    }
    [...]

    2) Merge conflict in drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c between
    9647c57b11e5 ("xsk: i40e: ice: ixgbe: mlx5: Test for dma_need_sync earlier for
    better performance") in bpf-next and e20f0dbf204f ("net/mlx5e: RX, Add a prefetch
    command for small L1_CACHE_BYTES") in net-next. Resolve the two locations by retaining
    net_prefetch() and taking xsk_buff_dma_sync_for_cpu() from bpf-next. Should look like:

    [...]
    xdp_set_data_meta_invalid(xdp);
    xsk_buff_dma_sync_for_cpu(xdp, rq->xsk_pool);
    net_prefetch(xdp->data);
    [...]

    We've added 133 non-merge commits during the last 14 day(s) which contain
    a total of 246 files changed, 13832 insertions(+), 3105 deletions(-).

    The main changes are:

    1) Initial support for sleepable BPF programs along with bpf_copy_from_user() helper
    for tracing to reliably access user memory, from Alexei Starovoitov.

    2) Add BPF infra for writing and parsing TCP header options, from Martin KaFai Lau.

    3) bpf_d_path() helper for returning full path for given 'struct path', from Jiri Olsa.

    4) AF_XDP support for shared umems between devices and queues, from Magnus Karlsson.

    5) Initial prep work for full BPF-to-BPF call support in libbpf, from Andrii Nakryiko.

    6) Generalize bpf_sk_storage map & add local storage for inodes, from KP Singh.

    7) Implement sockmap/hash updates from BPF context, from Lorenz Bauer.

    8) BPF xor verification for scalar types & add BPF link iterator, from Yonghong Song.

    9) Use target's prog type for BPF_PROG_TYPE_EXT prog verification, from Udip Pant.

    10) Rework BPF tracing samples to use libbpf loader, from Daniel T. Lee.

    11) Fix xdpsock sample to really cycle through all buffers, from Weqaar Janjua.

    12) Improve type safety for tun/veth XDP frame handling, from Maciej Żenczykowski.

    13) Various smaller cleanups and improvements all over the place.
    ====================

    Signed-off-by: David S. Miller

    David S. Miller
     

28 Aug, 2020

1 commit

  • The system for "Auto-detecting system features" located under
    tools/build/ are (currently) used by perf, libbpf and bpftool. It can
    contain stalled feature detection files, which are not cleaned up by
    libbpf and bpftool on make clean (side-note: perf tool is correct).

    Fix this by making the users invoke the make clean target.

    Some details about the changes. The libbpf Makefile already had a
    clean-config target (which seems to be copy-pasted from perf), but this
    target was not "connected" (a make dependency) to clean target. Choose
    not to rename target as someone might be using it. Did change the output
    from "CLEAN config" to "CLEAN feature-detect", to make it more clear
    what happens.

    This is related to the complaint and troubleshooting in the following
    link: https://lore.kernel.org/lkml/20200818122007.2d1cfe2d@carbon/

    Signed-off-by: Jesper Dangaard Brouer
    Signed-off-by: Daniel Borkmann
    Acked-by: Jiri Olsa
    Link: https://lore.kernel.org/lkml/20200818122007.2d1cfe2d@carbon/
    Link: https://lore.kernel.org/bpf/159851841661.1072907.13770213104521805592.stgit@firesoul

    Jesper Dangaard Brouer
     

26 Aug, 2020

1 commit

  • Similar to bpf_local_storage for sockets, add local storage for inodes.
    The life-cycle of storage is managed with the life-cycle of the inode.
    i.e. the storage is destroyed along with the owning inode.

    The BPF LSM allocates an __rcu pointer to the bpf_local_storage in the
    security blob which are now stackable and can co-exist with other LSMs.

    Signed-off-by: KP Singh
    Signed-off-by: Alexei Starovoitov
    Link: https://lore.kernel.org/bpf/20200825182919.1118197-6-kpsingh@chromium.org

    KP Singh
     

22 Aug, 2020

1 commit

  • The link query for bpf iterators is implemented.
    Besides being shown to the user what bpf iterator
    the link represents, the target_name is also used
    to filter out what additional information should be
    printed out, e.g., whether map_id should be shown or not.
    The following is an example of bpf_iter link dump,
    plain output or pretty output.

    $ bpftool link show
    11: iter prog 59 target_name task
    pids test_progs(1749)
    34: iter prog 173 target_name bpf_map_elem map_id 127
    pids test_progs_1(1753)
    $ bpftool -p link show
    [{
    "id": 11,
    "type": "iter",
    "prog_id": 59,
    "target_name": "task",
    "pids": [{
    "pid": 1749,
    "comm": "test_progs"
    }
    ]
    },{
    "id": 34,
    "type": "iter",
    "prog_id": 173,
    "target_name": "bpf_map_elem",
    "map_id": 127,
    "pids": [{
    "pid": 1753,
    "comm": "test_progs_1"
    }
    ]
    }
    ]

    Signed-off-by: Yonghong Song
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20200821184420.574430-1-yhs@fb.com

    Yonghong Song
     

19 Aug, 2020

2 commits

  • Most netlink-related functions were unique to bpftool usage, so I moved them
    into net.c. Few functions are still used by both bpftool and libbpf itself
    internally, so I've copy-pasted them (libbpf_nl_get_link,
    libbpf_netlink_open). It's a bit of duplication of code, but better separation
    of libbpf as a library with public API and bpftool, relying on unexposed
    functions in libbpf.

    Signed-off-by: Andrii Nakryiko
    Signed-off-by: Alexei Starovoitov
    Link: https://lore.kernel.org/bpf/20200819013607.3607269-3-andriin@fb.com

    Andrii Nakryiko
     
  • 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
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Link: https://lore.kernel.org/bpf/20200818222312.2181675-1-yhs@fb.com

    Yonghong Song
     

14 Aug, 2020

2 commits


13 Aug, 2020

1 commit

  • Seems like C++17 standard mode doesn't recognize typeof() anymore. This can
    be tested by compiling test_cpp test with -std=c++17 or -std=c++1z options.
    The use of typeof in skeleton generated code is unnecessary, all types are
    well-known at the time of code generation, so remove all typeof()'s to make
    skeleton code more future-proof when interacting with C++ compilers.

    Fixes: 985ead416df3 ("bpftool: Add skeleton codegen command")
    Signed-off-by: Andrii Nakryiko
    Signed-off-by: Alexei Starovoitov
    Acked-by: Song Liu
    Link: https://lore.kernel.org/bpf/20200812025907.1371956-1-andriin@fb.com

    Andrii Nakryiko
     

07 Aug, 2020

1 commit

  • Previous commit adjusted kernel uapi for map
    element bpf iterator. This patch adjusted libbpf API
    due to uapi change. bpftool and bpf_iter selftests
    are also changed accordingly.

    Signed-off-by: Yonghong Song
    Signed-off-by: Alexei Starovoitov
    Acked-by: Andrii Nakryiko
    Acked-by: John Fastabend
    Link: https://lore.kernel.org/bpf/20200805055058.1457623-1-yhs@fb.com

    Yonghong Song
     

03 Aug, 2020

2 commits


02 Aug, 2020

2 commits


28 Jul, 2020

2 commits

  • Assign "lsm" as a printed name for BPF_PROG_TYPE_LSM in bpftool, so that
    it can use it when listing programs loaded on the system or when probing
    features.

    Signed-off-by: Quentin Monnet
    Signed-off-by: Daniel Borkmann
    Link: https://lore.kernel.org/bpf/20200724090618.16378-3-quentin@isovalent.com

    Quentin Monnet
     
  • For probing program and map types, bpftool loops on type values and uses
    the relevant type name in prog_type_name[] or map_type_name[]. To ensure
    the name exists, we exit from the loop if we go over the size of the
    array.

    However, this is not enough in the case where the arrays have "holes" in
    them, program or map types for which they have no name, but not at the
    end of the list. This is currently the case for BPF_PROG_TYPE_LSM, not
    known to bpftool and which name is a null string. When probing for
    features, bpftool attempts to strlen() that name and segfaults.

    Let's fix it by skipping probes for "unknown" program and map types,
    with an informational message giving the numeral value in that case.

    Fixes: 93a3545d812a ("tools/bpftool: Add name mappings for SK_LOOKUP prog and attach type")
    Reported-by: Paul Chaignon
    Signed-off-by: Quentin Monnet
    Signed-off-by: Daniel Borkmann
    Link: https://lore.kernel.org/bpf/20200724090618.16378-2-quentin@isovalent.com

    Quentin Monnet
     

26 Jul, 2020

2 commits

  • The optional parameter "map MAP" can be added to "bpftool iter"
    command to create a bpf iterator for map elements. For example,
    bpftool iter pin ./prog.o /sys/fs/bpf/p1 map id 333

    For map element bpf iterator "map MAP" parameter is required.
    Otherwise, bpf link creation will return an error.

    Quentin Monnet kindly provided bash-completion implementation
    for new "map MAP" option.

    Signed-off-by: Yonghong Song
    Signed-off-by: Alexei Starovoitov
    Link: https://lore.kernel.org/bpf/20200723184119.590799-1-yhs@fb.com

    Yonghong Song
     
  • Strip away DWARF info from .bpf.o files, before generating BPF skeletons.
    This reduces bpftool binary size from 3.43MB to 2.58MB.

    Signed-off-by: Andrii Nakryiko
    Signed-off-by: Alexei Starovoitov
    Acked-by: Quentin Monnet
    Link: https://lore.kernel.org/bpf/20200722043804.2373298-1-andriin@fb.com

    Andrii Nakryiko
     

22 Jul, 2020

2 commits

  • The bpftool sources include code to walk file trees, but use multiple
    frameworks to do so: nftw and fts. While nftw conforms to POSIX/SUSv3 and
    is widely available, fts is not conformant and less common, especially on
    non-glibc systems. The inconsistent framework usage hampers maintenance
    and portability of bpftool, in particular for embedded systems.

    Standardize code usage by rewriting one fts-based function to use nftw and
    clean up some related function warnings by extending use of "const char *"
    arguments. This change helps in building bpftool against musl for OpenWrt.

    Also fix an unsafe call to dirname() by duplicating the string to pass,
    since some implementations may directly alter it. The same approach is
    used in libbpf.c.

    Signed-off-by: Tony Ambardar
    Signed-off-by: Daniel Borkmann
    Reviewed-by: Quentin Monnet
    Link: https://lore.kernel.org/bpf/20200721024817.13701-1-Tony.Ambardar@gmail.com

    Tony Ambardar
     
  • A handful of samples and selftests fail to build on s390, because
    after commit 0ebeea8ca8a4 ("bpf: Restrict bpf_probe_read{, str}()
    only to archs where they work") bpf_probe_read is not available
    anymore.

    Fix by using bpf_probe_read_kernel.

    Signed-off-by: Ilya Leoshkevich
    Signed-off-by: Alexei Starovoitov
    Link: https://lore.kernel.org/bpf/20200720114806.88823-1-iii@linux.ibm.com

    Ilya Leoshkevich