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

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

bpftool: Adjust for error codes from libbpf probes

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

Originally [1], libbpf's (now deprecated) probe functions returned a bool to acknowledge support but the new APIs return an int with a possible negative error code to reflect probe failure. This change decides for bpftool to declare maps and helpers are not available on probe failures. [1]: https://lore.kernel.org/bpf/20220202225916.3313522-3-andrii@kernel.org/ Signed-off-by: Milan Landaverde Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220504161356.3497972-2-milan@mdaverde.com

bpftool: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK

2022-04-11T03:17:16+00:00

We have switched to memcg-based memory accouting and thus the rlimit is not needed any more. LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK was introduced in libbpf for backward compatibility, so we can use it instead now. libbpf_set_strict_mode always return 0, so we don't need to check whether the return value is 0 or not. Signed-off-by: Yafang Shao Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220409125958.92629-4-laoar.shao@gmail.com

bpftool: Handle libbpf_probe_prog_type errors

2022-04-04T21:54:44+00:00

Previously [1], we were using bpf_probe_prog_type which returned a bool, but the new libbpf_probe_bpf_prog_type can return a negative error code on failure. This change decides for bpftool to declare a program type is not available on probe failure. [1] https://lore.kernel.org/bpf/20220202225916.3313522-3-andrii@kernel.org/ Signed-off-by: Milan Landaverde Signed-off-by: Andrii Nakryiko Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20220331154555.422506-4-milan@mdaverde.com