linux.git/tools/bpf/bpftool/feature.c, branch v6.7

bpftool: Use "fallthrough;" keyword instead of comments

2023-07-12T21:50:11+00:00

After using "__fallthrough;" in a switch/case block in bpftool's
btf_dumper.c [0], and then turning it into a comment [1] to prevent a
merge conflict in linux-next when the keyword was changed into just
"fallthrough;" [2], we can now drop the comment and use the new keyword,
no underscores.

Also update the other occurrence of "/* fallthrough */" in bpftool.

[0] commit 9fd496848b1c ("bpftool: Support inline annotations when dumping the CFG of a program")
[1] commit 4b7ef71ac977 ("bpftool: Replace "__fallthrough" by a comment to address merge conflict")
[2] commit f7a858bffcdd ("tools: Rename __fallthrough to fallthrough")

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

bpftool: JIT limited misreported as negative value on aarch64

2023-05-15T19:14:48+00:00

On aarch64, "bpftool feature" reports an incorrect BPF JIT limit:

$ sudo /sbin/bpftool feature
Scanning system configuration...
bpf() syscall restricted to privileged users
JIT compiler is enabled
JIT compiler hardening is disabled
JIT compiler kallsyms exports are enabled for root
skipping kernel config, can't open file: No such file or directory
Global memory limit for JIT compiler for unprivileged users is -201326592 bytes

This is because /proc/sys/net/core/bpf_jit_limit reports

$ sudo cat /proc/sys/net/core/bpf_jit_limit
68169519595520

...and an int is assumed in read_procfs().  Change read_procfs()
to return a long to avoid negative value reporting.

Fixes: 7a4522bbef0c ("tools: bpftool: add probes for /proc/ eBPF parameters")
Reported-by: Nicky Veitch 
Signed-off-by: Alan Maguire 
Signed-off-by: Daniel Borkmann 
Acked-by: Jiri Olsa 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20230512113134.58996-1-alan.maguire@oracle.com

bpftool: fix output for skipping kernel config check

2023-01-11T01:42:31+00:00

When bpftool feature does not find kernel config
files under default path or wrong format,
do not output CONFIG_XYZ is not set.
Skip kernel config check and continue.

Signed-off-by: Chethan Suresh 
Signed-off-by: Kenta Tada 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/r/20230109023742.29657-1-chethan.suresh@sony.com
Signed-off-by: Martin KaFai Lau

bpftool: Fix a typo in a comment

2022-08-15T15:29:42+00:00

This is the wrong library name: libcap, not libpcap.

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

bpftool: Rename "bpftool feature list" into "... feature list_builtins"

2022-07-05T09:53:54+00:00

To make it more explicit that the features listed with "bpftool feature
list" are known to bpftool, but not necessary available on the system
(as opposed to the probed features), rename the "feature list" command
into "feature list_builtins".

Note that "bpftool feature list" still works as before given that we
recognise arguments from their prefixes; but the real name of the
subcommand, in particular as displayed in the man page or the
interactive help, will now include "_builtins".

Since we update the bash completion accordingly, let's also take this
chance to redirect error output to /dev/null in the completion script,
to avoid displaying unexpected error messages when users attempt to
tab-complete.

Suggested-by: Daniel Borkmann 
Signed-off-by: Quentin Monnet 
Signed-off-by: Daniel Borkmann 
Acked-by: Yonghong Song 
Link: https://lore.kernel.org/bpf/20220701093805.16920-1-quentin@isovalent.com

bpftool: Add feature list (prog/map/link/attach types, helpers)

2022-06-30T14:17:03+00:00

Add a "bpftool feature list" subcommand to list BPF "features".
Contrarily to "bpftool feature probe", this is not about the features
available on the system. Instead, it lists all features known to bpftool
from compilation time; in other words, all program, map, attach, link
types known to the libbpf version in use, and all helpers found in the
UAPI BPF header.

The first use case for this feature is bash completion: running the
command provides a list of types that can be used to produce the list of
candidate map types, for example.

Now that bpftool uses "standard" names provided by libbpf for the
program, map, link, and attach types, having the ability to list these
types and helpers could also be useful in scripts to loop over existing
items.

Sample output:

    # bpftool feature list prog_types | grep -vw unspec | head -n 6
    socket_filter
    kprobe
    sched_cls
    sched_act
    tracepoint
    xdp

    # bpftool -p feature list map_types | jq '.[1]'
    "hash"

    # bpftool feature list attach_types | grep '^cgroup_'
    cgroup_inet_ingress
    cgroup_inet_egress
    [...]
    cgroup_inet_sock_release

    # bpftool feature list helpers | grep -vw bpf_unspec | wc -l
    207

The "unspec" types and helpers are not filtered out by bpftool, so as to
remain closer to the enums, and to preserve the indices in the JSON
arrays (e.g. "hash" at index 1 == BPF_MAP_TYPE_HASH in map types list).

Signed-off-by: Quentin Monnet 
Signed-off-by: Daniel Borkmann 
Acked-by: Daniel Müller 
Link: https://lore.kernel.org/bpf/20220629203637.138944-2-quentin@isovalent.com

Revert "bpftool: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK"

2022-06-14T20:18:06+00:00

This reverts commit a777e18f1bcd32528ff5dfd10a6629b655b05eb8.

In commit a777e18f1bcd ("bpftool: Use libbpf 1.0 API mode instead of
RLIMIT_MEMLOCK"), we removed the rlimit bump in bpftool, because the
kernel has switched to memcg-based memory accounting. Thanks to the
LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK, we attempted to keep compatibility
with other systems and ask libbpf to raise the limit for us if
necessary.

How do we know if memcg-based accounting is supported? There is a probe
in libbpf to check this. But this probe currently relies on the
availability of a given BPF helper, bpf_ktime_get_coarse_ns(), which
landed in the same kernel version as the memory accounting change. This
works in the generic case, but it may fail, for example, if the helper
function has been backported to an older kernel. This has been observed
for Google Cloud's Container-Optimized OS (COS), where the helper is
available but rlimit is still in use. The probe succeeds, the rlimit is
not raised, and probing features with bpftool, for example, fails.

A patch was submitted [0] to update this probe in libbpf, based on what
the cilium/ebpf Go library does [1]. It would lower the soft rlimit to
0, attempt to load a BPF object, and reset the rlimit. But it may induce
some hard-to-debug flakiness if another process starts, or the current
application is killed, while the rlimit is reduced, and the approach was
discarded.

As a workaround to ensure that the rlimit bump does not depend on the
availability of a given helper, we restore the unconditional rlimit bump
in bpftool for now.

  [0] https://lore.kernel.org/bpf/20220609143614.97837-1-quentin@isovalent.com/
  [1] https://github.com/cilium/ebpf/blob/v0.9.0/rlimit/rlimit.go#L39

Signed-off-by: Quentin Monnet 
Signed-off-by: Daniel Borkmann 
Cc: Yafang Shao 
Cc: Stanislav Fomichev 
Link: https://lore.kernel.org/bpf/20220610112648.29695-2-quentin@isovalent.com

bpftool: Use libbpf_bpf_map_type_str

2022-06-02T23:26:24+00:00

This change switches bpftool over to using the recently introduced
libbpf_bpf_map_type_str function instead of maintaining its own string
representation for the bpf_map_type enum.

Signed-off-by: Daniel Müller 
Signed-off-by: Andrii Nakryiko 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20220523230428.3077108-7-deso@posteo.net

bpftool: Use libbpf_bpf_prog_type_str

2022-06-02T23:26:18+00:00

This change switches bpftool over to using the recently introduced
libbpf_bpf_prog_type_str function instead of maintaining its own string
representation for the bpf_prog_type enum.

Signed-off-by: Daniel Müller 
Signed-off-by: Andrii Nakryiko 
Acked-by: Yonghong Song 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20220523230428.3077108-4-deso@posteo.net

bpftool: Output message if no helpers found in feature probing

2022-05-10T00:16:05+00:00

Currently in libbpf, we have hardcoded program types that are not
supported for helper function probing (e.g. tracing, ext, lsm).
Due to this (and other legitimate failures), bpftool feature probe returns
empty for those program type helper functions.

Instead of implying to the user that there are no helper functions
available for a program type, we output a message to the user explaining
that helper function probing failed for that program type.

Signed-off-by: Milan Landaverde 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20220504161356.3497972-3-milan@mdaverde.com