linux-stable.git/tools/bpf/bpftool/struct_ops.c, branch v6.2

bpftool: clean-up usage of libbpf_get_error()

2022-11-21T00:17:46+00:00

bpftool is now totally compliant with libbpf 1.0 mode and is not
expected to be compiled with pre-1.0, let's clean-up the usage of
libbpf_get_error().

The changes stay aligned with returned errors always negative.

- In tools/bpf/bpftool/btf.c This fixes an uninitialized local
variable `err` in function do_dump() because it may now be returned
without having been set.
- This also removes the checks on NULL pointers before calling
btf__free() because that function already does the check.

Signed-off-by: Sahid Orentino Ferdjaoui 
Link: https://lore.kernel.org/r/20221120112515.38165-5-sahid.ferdjaoui@industrialdiscipline.com
Signed-off-by: Alexei Starovoitov

bpftool: fix error message when function can't register struct_ops

2022-11-21T00:17:46+00:00

It is expected that errno be passed to strerror(). This also cleans
this part of code from using libbpf_get_error().

Signed-off-by: Sahid Orentino Ferdjaoui 
Acked-by: Yonghong Song 
Suggested-by: Quentin Monnet 
Reviewed-by: Quentin Monnet 
Link: https://lore.kernel.org/r/20221120112515.38165-4-sahid.ferdjaoui@industrialdiscipline.com
Signed-off-by: Alexei Starovoitov

bpftool: replace return value PTR_ERR(NULL) with 0

2022-11-21T00:17:46+00:00

There is no reasons to keep PTR_ERR() when kern_btf=NULL, let's just
return 0.
This also cleans this part of code from using libbpf_get_error().

Signed-off-by: Sahid Orentino Ferdjaoui 
Acked-by: Yonghong Song 
Suggested-by: Quentin Monnet 
Link: https://lore.kernel.org/r/20221120112515.38165-3-sahid.ferdjaoui@industrialdiscipline.com
Signed-off-by: Alexei Starovoitov

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 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: Stop using bpf_map__def() API

2022-01-13T01:01:38+00:00

libbpf bpf_map__def() API is being deprecated, replace bpftool's
usage with the appropriate getters and setters

Signed-off-by: Christy Lee 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20220108004218.355761-3-christylee@fb.com

bpftool: Switch bpf_object__load_xattr() to bpf_object__load()

2021-12-10T23:29:18+00:00

Switch all the uses of to-be-deprecated bpf_object__load_xattr() into
a simple bpf_object__load() calls with optional log_level passed through
open_opts.kernel_log_level, if -d option is specified.

Signed-off-by: Andrii Nakryiko 
Signed-off-by: Alexei Starovoitov 
Link: https://lore.kernel.org/bpf/20211209193840.1248570-13-andrii@kernel.org

bpftool: Use libbpf_get_error() to check error

2021-11-15T02:38:13+00:00

Currently, LIBBPF_STRICT_ALL mode is enabled by default for
bpftool which means on error cases, some libbpf APIs would
return NULL pointers. This makes IS_ERR check failed to detect
such cases and result in segfault error. Use libbpf_get_error()
instead like we do in libbpf itself.

Signed-off-by: Hengqi Chen 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20211115012436.3143318-1-hengqi.chen@gmail.com

bpftool: Migrate -1 err checks of libbpf fn calls

2021-11-03T18:22:30+00:00

Per [0], callers of libbpf functions with LIBBPF_STRICT_DIRECT_ERRS set
should handle negative error codes of various values (e.g. -EINVAL).
Migrate two callsites which were explicitly checking for -1 only to
handle the new scheme.

  [0]: https://github.com/libbpf/libbpf/wiki/Libbpf-1.0-migration-guide#direct-error-code-returning-libbpf_strict_direct_errs

Signed-off-by: Dave Marchevsky 
Signed-off-by: Andrii Nakryiko 
Acked-by: Quentin Monnet 
Link: https://lore.kernel.org/bpf/20211101224357.2651181-2-davemarchevsky@fb.com

tools: bpftool: Update and synchronise option list in doc and help msg

2021-07-30T22:40:27+00:00

All bpftool commands support the options for JSON output and debug from
libbpf. In addition, some commands support additional options
corresponding to specific use cases.

The list of options described in the man pages for the different
commands are not always accurate. The messages for interactive help are
mostly limited to HELP_SPEC_OPTIONS, and are even less representative of
the actual set of options supported for the commands.

Let's update the lists:

- HELP_SPEC_OPTIONS is modified to contain the "default" options (JSON
  and debug), and to be extensible (no ending curly bracket).
- All commands use HELP_SPEC_OPTIONS in their help message, and then
  complete the list with their specific options.
- The lists of options in the man pages are updated.
- The formatting of the list for bpftool.rst is adjusted to match
  formatting for the other man pages. This is for consistency, and also
  because it will be helpful in a future patch to automatically check
  that the files are synchronised.

Signed-off-by: Quentin Monnet 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20210730215435.7095-5-quentin@isovalent.com