2018-12-12 19:59:25 -08:00
|
|
|
// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
|
|
|
/* Copyright (C) 2017-2018 Netronome Systems, Inc. */
|
2017-10-04 20:10:04 -07:00
|
|
|
|
|
|
|
#include <ctype.h>
|
|
|
|
#include <errno.h>
|
2017-10-23 09:24:06 -07:00
|
|
|
#include <getopt.h>
|
2017-10-04 20:10:04 -07:00
|
|
|
#include <linux/bpf.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
2020-01-20 14:06:46 +01:00
|
|
|
#include <bpf/bpf.h>
|
2020-11-04 20:34:01 -08:00
|
|
|
#include <bpf/btf.h>
|
bpftool: Switch to libbpf's hashmap for PIDs/names references
In order to show PIDs and names for processes holding references to BPF
programs, maps, links, or BTF objects, bpftool creates hash maps to
store all relevant information. This commit is part of a set that
transitions from the kernel's hash map implementation to the one coming
with libbpf.
The motivation is to make bpftool less dependent of kernel headers, to
ease the path to a potential out-of-tree mirror, like libbpf has.
This is the third and final step of the transition, in which we convert
the hash maps used for storing the information about the processes
holding references to BPF objects (programs, maps, links, BTF), and at
last we drop the inclusion of tools/include/linux/hashtable.h.
Note: Checkpatch complains about the use of __weak declarations, and the
missing empty lines after the bunch of empty function declarations when
compiling without the BPF skeletons (none of these were introduced in
this patch). We want to keep things as they are, and the reports should
be safe to ignore.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-6-quentin@isovalent.com
2021-10-23 21:51:54 +01:00
|
|
|
#include <bpf/hashmap.h>
|
|
|
|
#include <bpf/libbpf.h>
|
2017-10-04 20:10:04 -07:00
|
|
|
|
|
|
|
#include "main.h"
|
|
|
|
|
2018-03-01 20:20:09 -08:00
|
|
|
#define BATCH_LINE_LEN_MAX 65536
|
|
|
|
#define BATCH_ARG_NB_MAX 4096
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
const char *bin_name;
|
|
|
|
static int last_argc;
|
|
|
|
static char **last_argv;
|
|
|
|
static int (*last_do_help)(int argc, char **argv);
|
2017-10-23 09:24:07 -07:00
|
|
|
json_writer_t *json_wtr;
|
|
|
|
bool pretty_output;
|
|
|
|
bool json_output;
|
2017-11-08 13:55:49 +09:00
|
|
|
bool show_pinned;
|
2018-12-18 10:13:19 +00:00
|
|
|
bool block_mount;
|
2019-05-24 11:36:48 +01:00
|
|
|
bool verifier_logs;
|
2019-10-07 15:56:04 -07:00
|
|
|
bool relaxed_maps;
|
2021-05-13 17:36:19 -07:00
|
|
|
bool use_loader;
|
2021-11-10 11:23:24 -08:00
|
|
|
bool legacy_libbpf;
|
2020-11-04 20:34:01 -08:00
|
|
|
struct btf *base_btf;
|
bpftool: Switch to libbpf's hashmap for PIDs/names references
In order to show PIDs and names for processes holding references to BPF
programs, maps, links, or BTF objects, bpftool creates hash maps to
store all relevant information. This commit is part of a set that
transitions from the kernel's hash map implementation to the one coming
with libbpf.
The motivation is to make bpftool less dependent of kernel headers, to
ease the path to a potential out-of-tree mirror, like libbpf has.
This is the third and final step of the transition, in which we convert
the hash maps used for storing the information about the processes
holding references to BPF objects (programs, maps, links, BTF), and at
last we drop the inclusion of tools/include/linux/hashtable.h.
Note: Checkpatch complains about the use of __weak declarations, and the
missing empty lines after the bunch of empty function declarations when
compiling without the BPF skeletons (none of these were introduced in
this patch). We want to keep things as they are, and the reports should
be safe to ignore.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-6-quentin@isovalent.com
2021-10-23 21:51:54 +01:00
|
|
|
struct hashmap *refs_table;
|
2017-10-04 20:10:04 -07:00
|
|
|
|
2017-11-28 17:44:29 -08:00
|
|
|
static void __noreturn clean_and_exit(int i)
|
|
|
|
{
|
|
|
|
if (json_output)
|
|
|
|
jsonw_destroy(&json_wtr);
|
|
|
|
|
|
|
|
exit(i);
|
|
|
|
}
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
void usage(void)
|
|
|
|
{
|
|
|
|
last_do_help(last_argc - 1, last_argv + 1);
|
|
|
|
|
2017-11-28 17:44:29 -08:00
|
|
|
clean_and_exit(-1);
|
2017-10-04 20:10:04 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int do_help(int argc, char **argv)
|
|
|
|
{
|
2017-10-23 09:24:14 -07:00
|
|
|
if (json_output) {
|
|
|
|
jsonw_null(json_wtr);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
fprintf(stderr,
|
2017-10-23 09:24:16 -07:00
|
|
|
"Usage: %s [OPTIONS] OBJECT { COMMAND | help }\n"
|
2017-10-04 20:10:04 -07:00
|
|
|
" %s batch file FILE\n"
|
2017-10-19 15:46:26 -07:00
|
|
|
" %s version\n"
|
2017-10-04 20:10:04 -07:00
|
|
|
"\n"
|
2020-05-09 10:59:20 -07:00
|
|
|
" OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }\n"
|
2021-07-30 22:54:32 +01:00
|
|
|
" " HELP_SPEC_OPTIONS " |\n"
|
|
|
|
" {-V|--version} }\n"
|
2017-10-23 09:24:16 -07:00
|
|
|
"",
|
2017-10-19 15:46:26 -07:00
|
|
|
bin_name, bin_name, bin_name);
|
2017-10-04 20:10:04 -07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
bpftool: Update versioning scheme, align on libbpf's version number
Since the notion of versions was introduced for bpftool, it has been
following the version number of the kernel (using the version number
corresponding to the tree in which bpftool's sources are located). The
rationale was that bpftool's features are loosely tied to BPF features
in the kernel, and that we could defer versioning to the kernel
repository itself.
But this versioning scheme is confusing today, because a bpftool binary
should be able to work with both older and newer kernels, even if some
of its recent features won't be available on older systems. Furthermore,
if bpftool is ported to other systems in the future, keeping a
Linux-based version number is not a good option.
Looking at other options, we could either have a totally independent
scheme for bpftool, or we could align it on libbpf's version number
(with an offset on the major version number, to avoid going backwards).
The latter comes with a few drawbacks:
- We may want bpftool releases in-between two libbpf versions. We can
always append pre-release numbers to distinguish versions, although
those won't look as "official" as something with a proper release
number. But at the same time, having bpftool with version numbers that
look "official" hasn't really been an issue so far.
- If no new feature lands in bpftool for some time, we may move from
e.g. 6.7.0 to 6.8.0 when libbpf levels up and have two different
versions which are in fact the same.
- Following libbpf's versioning scheme sounds better than kernel's, but
ultimately it doesn't make too much sense either, because even though
bpftool uses the lib a lot, its behaviour is not that much conditioned
by the internal evolution of the library (or by new APIs that it may
not use).
Having an independent versioning scheme solves the above, but at the
cost of heavier maintenance. Developers will likely forget to increase
the numbers when adding features or bug fixes, and we would take the
risk of having to send occasional "catch-up" patches just to update the
version number.
Based on these considerations, this patch aligns bpftool's version
number on libbpf's. This is not a perfect solution, but 1) it's
certainly an improvement over the current scheme, 2) the issues raised
above are all minor at the moment, and 3) we can still move to an
independent scheme in the future if we realise we need it.
Given that libbpf is currently at version 0.7.0, and bpftool, before
this patch, was at 5.16, we use an offset of 6 for the major version,
bumping bpftool to 6.7.0. Libbpf does not export its patch number;
leave bpftool's patch number at 0 for now.
It remains possible to manually override the version number by setting
BPFTOOL_VERSION when calling make.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
2022-02-10 10:42:37 +00:00
|
|
|
#ifndef BPFTOOL_VERSION
|
|
|
|
/* bpftool's major and minor version numbers are aligned on libbpf's. There is
|
|
|
|
* an offset of 6 for the version number, because bpftool's version was higher
|
|
|
|
* than libbpf's when we adopted this scheme. The patch number remains at 0
|
|
|
|
* for now. Set BPFTOOL_VERSION to override.
|
|
|
|
*/
|
|
|
|
#define BPFTOOL_MAJOR_VERSION (LIBBPF_MAJOR_VERSION + 6)
|
|
|
|
#define BPFTOOL_MINOR_VERSION LIBBPF_MINOR_VERSION
|
|
|
|
#define BPFTOOL_PATCH_VERSION 0
|
|
|
|
#endif
|
|
|
|
|
2017-10-19 15:46:26 -07:00
|
|
|
static int do_version(int argc, char **argv)
|
|
|
|
{
|
tools: bpftool: Print optional built-in features along with version
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 <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
#ifdef HAVE_LIBBFD_SUPPORT
|
|
|
|
const bool has_libbfd = true;
|
|
|
|
#else
|
|
|
|
const bool has_libbfd = false;
|
|
|
|
#endif
|
|
|
|
#ifdef BPFTOOL_WITHOUT_SKELETONS
|
|
|
|
const bool has_skeletons = false;
|
|
|
|
#else
|
|
|
|
const bool has_skeletons = true;
|
|
|
|
#endif
|
|
|
|
|
2017-10-23 09:24:14 -07:00
|
|
|
if (json_output) {
|
tools: bpftool: Print optional built-in features along with version
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 <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
jsonw_start_object(json_wtr); /* root object */
|
|
|
|
|
2017-10-23 09:24:14 -07:00
|
|
|
jsonw_name(json_wtr, "version");
|
bpftool: Update versioning scheme, align on libbpf's version number
Since the notion of versions was introduced for bpftool, it has been
following the version number of the kernel (using the version number
corresponding to the tree in which bpftool's sources are located). The
rationale was that bpftool's features are loosely tied to BPF features
in the kernel, and that we could defer versioning to the kernel
repository itself.
But this versioning scheme is confusing today, because a bpftool binary
should be able to work with both older and newer kernels, even if some
of its recent features won't be available on older systems. Furthermore,
if bpftool is ported to other systems in the future, keeping a
Linux-based version number is not a good option.
Looking at other options, we could either have a totally independent
scheme for bpftool, or we could align it on libbpf's version number
(with an offset on the major version number, to avoid going backwards).
The latter comes with a few drawbacks:
- We may want bpftool releases in-between two libbpf versions. We can
always append pre-release numbers to distinguish versions, although
those won't look as "official" as something with a proper release
number. But at the same time, having bpftool with version numbers that
look "official" hasn't really been an issue so far.
- If no new feature lands in bpftool for some time, we may move from
e.g. 6.7.0 to 6.8.0 when libbpf levels up and have two different
versions which are in fact the same.
- Following libbpf's versioning scheme sounds better than kernel's, but
ultimately it doesn't make too much sense either, because even though
bpftool uses the lib a lot, its behaviour is not that much conditioned
by the internal evolution of the library (or by new APIs that it may
not use).
Having an independent versioning scheme solves the above, but at the
cost of heavier maintenance. Developers will likely forget to increase
the numbers when adding features or bug fixes, and we would take the
risk of having to send occasional "catch-up" patches just to update the
version number.
Based on these considerations, this patch aligns bpftool's version
number on libbpf's. This is not a perfect solution, but 1) it's
certainly an improvement over the current scheme, 2) the issues raised
above are all minor at the moment, and 3) we can still move to an
independent scheme in the future if we realise we need it.
Given that libbpf is currently at version 0.7.0, and bpftool, before
this patch, was at 5.16, we use an offset of 6 for the major version,
bumping bpftool to 6.7.0. Libbpf does not export its patch number;
leave bpftool's patch number at 0 for now.
It remains possible to manually override the version number by setting
BPFTOOL_VERSION when calling make.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
2022-02-10 10:42:37 +00:00
|
|
|
#ifdef BPFTOOL_VERSION
|
2017-12-27 19:16:28 +00:00
|
|
|
jsonw_printf(json_wtr, "\"%s\"", BPFTOOL_VERSION);
|
bpftool: Update versioning scheme, align on libbpf's version number
Since the notion of versions was introduced for bpftool, it has been
following the version number of the kernel (using the version number
corresponding to the tree in which bpftool's sources are located). The
rationale was that bpftool's features are loosely tied to BPF features
in the kernel, and that we could defer versioning to the kernel
repository itself.
But this versioning scheme is confusing today, because a bpftool binary
should be able to work with both older and newer kernels, even if some
of its recent features won't be available on older systems. Furthermore,
if bpftool is ported to other systems in the future, keeping a
Linux-based version number is not a good option.
Looking at other options, we could either have a totally independent
scheme for bpftool, or we could align it on libbpf's version number
(with an offset on the major version number, to avoid going backwards).
The latter comes with a few drawbacks:
- We may want bpftool releases in-between two libbpf versions. We can
always append pre-release numbers to distinguish versions, although
those won't look as "official" as something with a proper release
number. But at the same time, having bpftool with version numbers that
look "official" hasn't really been an issue so far.
- If no new feature lands in bpftool for some time, we may move from
e.g. 6.7.0 to 6.8.0 when libbpf levels up and have two different
versions which are in fact the same.
- Following libbpf's versioning scheme sounds better than kernel's, but
ultimately it doesn't make too much sense either, because even though
bpftool uses the lib a lot, its behaviour is not that much conditioned
by the internal evolution of the library (or by new APIs that it may
not use).
Having an independent versioning scheme solves the above, but at the
cost of heavier maintenance. Developers will likely forget to increase
the numbers when adding features or bug fixes, and we would take the
risk of having to send occasional "catch-up" patches just to update the
version number.
Based on these considerations, this patch aligns bpftool's version
number on libbpf's. This is not a perfect solution, but 1) it's
certainly an improvement over the current scheme, 2) the issues raised
above are all minor at the moment, and 3) we can still move to an
independent scheme in the future if we realise we need it.
Given that libbpf is currently at version 0.7.0, and bpftool, before
this patch, was at 5.16, we use an offset of 6 for the major version,
bumping bpftool to 6.7.0. Libbpf does not export its patch number;
leave bpftool's patch number at 0 for now.
It remains possible to manually override the version number by setting
BPFTOOL_VERSION when calling make.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
2022-02-10 10:42:37 +00:00
|
|
|
#else
|
|
|
|
jsonw_printf(json_wtr, "\"%d.%d.%d\"", BPFTOOL_MAJOR_VERSION,
|
|
|
|
BPFTOOL_MINOR_VERSION, BPFTOOL_PATCH_VERSION);
|
|
|
|
#endif
|
2022-02-10 10:42:36 +00:00
|
|
|
jsonw_name(json_wtr, "libbpf_version");
|
|
|
|
jsonw_printf(json_wtr, "\"%d.%d\"",
|
|
|
|
libbpf_major_version(), libbpf_minor_version());
|
tools: bpftool: Print optional built-in features along with version
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 <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
|
|
|
|
jsonw_name(json_wtr, "features");
|
|
|
|
jsonw_start_object(json_wtr); /* features */
|
|
|
|
jsonw_bool_field(json_wtr, "libbfd", has_libbfd);
|
bpftool: Add current libbpf_strict mode to version output
+ bpftool --legacy --version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool --version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --legacy --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --json --legacy version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":false,"skeletons":true}}
+ bpftool --json version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":true,"skeletons":true}}
Suggested-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20211116000448.2918854-1-sdf@google.com
2021-11-15 16:04:48 -08:00
|
|
|
jsonw_bool_field(json_wtr, "libbpf_strict", !legacy_libbpf);
|
tools: bpftool: Print optional built-in features along with version
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 <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
jsonw_bool_field(json_wtr, "skeletons", has_skeletons);
|
|
|
|
jsonw_end_object(json_wtr); /* features */
|
|
|
|
|
|
|
|
jsonw_end_object(json_wtr); /* root object */
|
2017-10-23 09:24:14 -07:00
|
|
|
} else {
|
tools: bpftool: Print optional built-in features along with version
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 <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
unsigned int nb_features = 0;
|
|
|
|
|
bpftool: Update versioning scheme, align on libbpf's version number
Since the notion of versions was introduced for bpftool, it has been
following the version number of the kernel (using the version number
corresponding to the tree in which bpftool's sources are located). The
rationale was that bpftool's features are loosely tied to BPF features
in the kernel, and that we could defer versioning to the kernel
repository itself.
But this versioning scheme is confusing today, because a bpftool binary
should be able to work with both older and newer kernels, even if some
of its recent features won't be available on older systems. Furthermore,
if bpftool is ported to other systems in the future, keeping a
Linux-based version number is not a good option.
Looking at other options, we could either have a totally independent
scheme for bpftool, or we could align it on libbpf's version number
(with an offset on the major version number, to avoid going backwards).
The latter comes with a few drawbacks:
- We may want bpftool releases in-between two libbpf versions. We can
always append pre-release numbers to distinguish versions, although
those won't look as "official" as something with a proper release
number. But at the same time, having bpftool with version numbers that
look "official" hasn't really been an issue so far.
- If no new feature lands in bpftool for some time, we may move from
e.g. 6.7.0 to 6.8.0 when libbpf levels up and have two different
versions which are in fact the same.
- Following libbpf's versioning scheme sounds better than kernel's, but
ultimately it doesn't make too much sense either, because even though
bpftool uses the lib a lot, its behaviour is not that much conditioned
by the internal evolution of the library (or by new APIs that it may
not use).
Having an independent versioning scheme solves the above, but at the
cost of heavier maintenance. Developers will likely forget to increase
the numbers when adding features or bug fixes, and we would take the
risk of having to send occasional "catch-up" patches just to update the
version number.
Based on these considerations, this patch aligns bpftool's version
number on libbpf's. This is not a perfect solution, but 1) it's
certainly an improvement over the current scheme, 2) the issues raised
above are all minor at the moment, and 3) we can still move to an
independent scheme in the future if we realise we need it.
Given that libbpf is currently at version 0.7.0, and bpftool, before
this patch, was at 5.16, we use an offset of 6 for the major version,
bumping bpftool to 6.7.0. Libbpf does not export its patch number;
leave bpftool's patch number at 0 for now.
It remains possible to manually override the version number by setting
BPFTOOL_VERSION when calling make.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
2022-02-10 10:42:37 +00:00
|
|
|
#ifdef BPFTOOL_VERSION
|
2017-12-27 19:16:28 +00:00
|
|
|
printf("%s v%s\n", bin_name, BPFTOOL_VERSION);
|
bpftool: Update versioning scheme, align on libbpf's version number
Since the notion of versions was introduced for bpftool, it has been
following the version number of the kernel (using the version number
corresponding to the tree in which bpftool's sources are located). The
rationale was that bpftool's features are loosely tied to BPF features
in the kernel, and that we could defer versioning to the kernel
repository itself.
But this versioning scheme is confusing today, because a bpftool binary
should be able to work with both older and newer kernels, even if some
of its recent features won't be available on older systems. Furthermore,
if bpftool is ported to other systems in the future, keeping a
Linux-based version number is not a good option.
Looking at other options, we could either have a totally independent
scheme for bpftool, or we could align it on libbpf's version number
(with an offset on the major version number, to avoid going backwards).
The latter comes with a few drawbacks:
- We may want bpftool releases in-between two libbpf versions. We can
always append pre-release numbers to distinguish versions, although
those won't look as "official" as something with a proper release
number. But at the same time, having bpftool with version numbers that
look "official" hasn't really been an issue so far.
- If no new feature lands in bpftool for some time, we may move from
e.g. 6.7.0 to 6.8.0 when libbpf levels up and have two different
versions which are in fact the same.
- Following libbpf's versioning scheme sounds better than kernel's, but
ultimately it doesn't make too much sense either, because even though
bpftool uses the lib a lot, its behaviour is not that much conditioned
by the internal evolution of the library (or by new APIs that it may
not use).
Having an independent versioning scheme solves the above, but at the
cost of heavier maintenance. Developers will likely forget to increase
the numbers when adding features or bug fixes, and we would take the
risk of having to send occasional "catch-up" patches just to update the
version number.
Based on these considerations, this patch aligns bpftool's version
number on libbpf's. This is not a perfect solution, but 1) it's
certainly an improvement over the current scheme, 2) the issues raised
above are all minor at the moment, and 3) we can still move to an
independent scheme in the future if we realise we need it.
Given that libbpf is currently at version 0.7.0, and bpftool, before
this patch, was at 5.16, we use an offset of 6 for the major version,
bumping bpftool to 6.7.0. Libbpf does not export its patch number;
leave bpftool's patch number at 0 for now.
It remains possible to manually override the version number by setting
BPFTOOL_VERSION when calling make.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
2022-02-10 10:42:37 +00:00
|
|
|
#else
|
|
|
|
printf("%s v%d.%d.%d\n", bin_name, BPFTOOL_MAJOR_VERSION,
|
|
|
|
BPFTOOL_MINOR_VERSION, BPFTOOL_PATCH_VERSION);
|
|
|
|
#endif
|
2022-02-10 10:42:36 +00:00
|
|
|
printf("using libbpf %s\n", libbpf_version_string());
|
tools: bpftool: Print optional built-in features along with version
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 <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
printf("features:");
|
|
|
|
if (has_libbfd) {
|
|
|
|
printf(" libbfd");
|
|
|
|
nb_features++;
|
|
|
|
}
|
bpftool: Add current libbpf_strict mode to version output
+ bpftool --legacy --version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool --version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --legacy --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --json --legacy version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":false,"skeletons":true}}
+ bpftool --json version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":true,"skeletons":true}}
Suggested-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20211116000448.2918854-1-sdf@google.com
2021-11-15 16:04:48 -08:00
|
|
|
if (!legacy_libbpf) {
|
|
|
|
printf("%s libbpf_strict", nb_features++ ? "," : "");
|
|
|
|
nb_features++;
|
|
|
|
}
|
tools: bpftool: Print optional built-in features along with version
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 <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
if (has_skeletons)
|
|
|
|
printf("%s skeletons", nb_features++ ? "," : "");
|
|
|
|
printf("\n");
|
2017-10-23 09:24:14 -07:00
|
|
|
}
|
2017-10-19 15:46:26 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
int cmd_select(const struct cmd *cmds, int argc, char **argv,
|
|
|
|
int (*help)(int argc, char **argv))
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
last_argc = argc;
|
|
|
|
last_argv = argv;
|
|
|
|
last_do_help = help;
|
|
|
|
|
|
|
|
if (argc < 1 && cmds[0].func)
|
|
|
|
return cmds[0].func(argc, argv);
|
|
|
|
|
2020-06-19 16:16:59 -07:00
|
|
|
for (i = 0; cmds[i].cmd; i++) {
|
|
|
|
if (is_prefix(*argv, cmds[i].cmd)) {
|
|
|
|
if (!cmds[i].func) {
|
|
|
|
p_err("command '%s' is not supported in bootstrap mode",
|
|
|
|
cmds[i].cmd);
|
|
|
|
return -1;
|
|
|
|
}
|
2017-10-04 20:10:04 -07:00
|
|
|
return cmds[i].func(argc - 1, argv + 1);
|
2020-06-19 16:16:59 -07:00
|
|
|
}
|
|
|
|
}
|
2017-10-04 20:10:04 -07:00
|
|
|
|
|
|
|
help(argc - 1, argv + 1);
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool is_prefix(const char *pfx, const char *str)
|
|
|
|
{
|
|
|
|
if (!pfx)
|
|
|
|
return false;
|
|
|
|
if (strlen(str) < strlen(pfx))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return !memcmp(str, pfx, strlen(pfx));
|
|
|
|
}
|
|
|
|
|
2019-07-05 18:54:33 +01:00
|
|
|
/* Last argument MUST be NULL pointer */
|
|
|
|
int detect_common_prefix(const char *arg, ...)
|
|
|
|
{
|
|
|
|
unsigned int count = 0;
|
|
|
|
const char *ref;
|
|
|
|
char msg[256];
|
|
|
|
va_list ap;
|
|
|
|
|
|
|
|
snprintf(msg, sizeof(msg), "ambiguous prefix: '%s' could be '", arg);
|
|
|
|
va_start(ap, arg);
|
|
|
|
while ((ref = va_arg(ap, const char *))) {
|
|
|
|
if (!is_prefix(arg, ref))
|
|
|
|
continue;
|
|
|
|
count++;
|
|
|
|
if (count > 1)
|
|
|
|
strncat(msg, "' or '", sizeof(msg) - strlen(msg) - 1);
|
|
|
|
strncat(msg, ref, sizeof(msg) - strlen(msg) - 1);
|
|
|
|
}
|
|
|
|
va_end(ap);
|
|
|
|
strncat(msg, "'", sizeof(msg) - strlen(msg) - 1);
|
|
|
|
|
|
|
|
if (count >= 2) {
|
2019-08-15 15:32:19 +01:00
|
|
|
p_err("%s", msg);
|
2019-07-05 18:54:33 +01:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-10-19 15:46:19 -07:00
|
|
|
void fprint_hex(FILE *f, void *arg, unsigned int n, const char *sep)
|
2017-10-04 20:10:04 -07:00
|
|
|
{
|
|
|
|
unsigned char *data = arg;
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
for (i = 0; i < n; i++) {
|
|
|
|
const char *pfx = "";
|
|
|
|
|
|
|
|
if (!i)
|
|
|
|
/* nothing */;
|
|
|
|
else if (!(i % 16))
|
2017-10-19 15:46:19 -07:00
|
|
|
fprintf(f, "\n");
|
2017-10-04 20:10:04 -07:00
|
|
|
else if (!(i % 8))
|
2017-10-19 15:46:19 -07:00
|
|
|
fprintf(f, " ");
|
2017-10-04 20:10:04 -07:00
|
|
|
else
|
|
|
|
pfx = sep;
|
|
|
|
|
2017-10-19 15:46:19 -07:00
|
|
|
fprintf(f, "%s%02hhx", i ? pfx : "", data[i]);
|
2017-10-04 20:10:04 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-01 20:20:11 -08:00
|
|
|
/* Split command line into argument vector. */
|
|
|
|
static int make_args(char *line, char *n_argv[], int maxargs, int cmd_nb)
|
|
|
|
{
|
|
|
|
static const char ws[] = " \t\r\n";
|
|
|
|
char *cp = line;
|
|
|
|
int n_argc = 0;
|
|
|
|
|
|
|
|
while (*cp) {
|
|
|
|
/* Skip leading whitespace. */
|
|
|
|
cp += strspn(cp, ws);
|
|
|
|
|
|
|
|
if (*cp == '\0')
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (n_argc >= (maxargs - 1)) {
|
|
|
|
p_err("too many arguments to command %d", cmd_nb);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Word begins with quote. */
|
|
|
|
if (*cp == '\'' || *cp == '"') {
|
|
|
|
char quote = *cp++;
|
|
|
|
|
|
|
|
n_argv[n_argc++] = cp;
|
|
|
|
/* Find ending quote. */
|
|
|
|
cp = strchr(cp, quote);
|
|
|
|
if (!cp) {
|
|
|
|
p_err("unterminated quoted string in command %d",
|
|
|
|
cmd_nb);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
n_argv[n_argc++] = cp;
|
|
|
|
|
|
|
|
/* Find end of word. */
|
|
|
|
cp += strcspn(cp, ws);
|
|
|
|
if (*cp == '\0')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Separate words. */
|
|
|
|
*cp++ = 0;
|
|
|
|
}
|
|
|
|
n_argv[n_argc] = NULL;
|
|
|
|
|
|
|
|
return n_argc;
|
|
|
|
}
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
static int do_batch(int argc, char **argv);
|
|
|
|
|
|
|
|
static const struct cmd cmds[] = {
|
|
|
|
{ "help", do_help },
|
|
|
|
{ "batch", do_batch },
|
|
|
|
{ "prog", do_prog },
|
|
|
|
{ "map", do_map },
|
2020-04-28 17:16:12 -07:00
|
|
|
{ "link", do_link },
|
2017-12-13 15:18:54 +00:00
|
|
|
{ "cgroup", do_cgroup },
|
tools/bpftool: add perf subcommand
The new command "bpftool perf [show | list]" will traverse
all processes under /proc, and if any fd is associated
with a perf event, it will print out related perf event
information. Documentation is also added.
Below is an example to show the results using bcc commands.
Running the following 4 bcc commands:
kprobe: trace.py '__x64_sys_nanosleep'
kretprobe: trace.py 'r::__x64_sys_nanosleep'
tracepoint: trace.py 't:syscalls:sys_enter_nanosleep'
uprobe: trace.py 'p:/home/yhs/a.out:main'
The bpftool command line and result:
$ bpftool perf
pid 21711 fd 5: prog_id 5 kprobe func __x64_sys_write offset 0
pid 21765 fd 5: prog_id 7 kretprobe func __x64_sys_nanosleep offset 0
pid 21767 fd 5: prog_id 8 tracepoint sys_enter_nanosleep
pid 21800 fd 5: prog_id 9 uprobe filename /home/yhs/a.out offset 1159
$ bpftool -j perf
[{"pid":21711,"fd":5,"prog_id":5,"fd_type":"kprobe","func":"__x64_sys_write","offset":0}, \
{"pid":21765,"fd":5,"prog_id":7,"fd_type":"kretprobe","func":"__x64_sys_nanosleep","offset":0}, \
{"pid":21767,"fd":5,"prog_id":8,"fd_type":"tracepoint","tracepoint":"sys_enter_nanosleep"}, \
{"pid":21800,"fd":5,"prog_id":9,"fd_type":"uprobe","filename":"/home/yhs/a.out","offset":1159}]
$ bpftool prog
5: kprobe name probe___x64_sys tag e495a0c82f2c7a8d gpl
loaded_at 2018-05-15T04:46:37-0700 uid 0
xlated 200B not jited memlock 4096B map_ids 4
7: kprobe name probe___x64_sys tag f2fdee479a503abf gpl
loaded_at 2018-05-15T04:48:32-0700 uid 0
xlated 200B not jited memlock 4096B map_ids 7
8: tracepoint name tracepoint__sys tag 5390badef2395fcf gpl
loaded_at 2018-05-15T04:48:48-0700 uid 0
xlated 200B not jited memlock 4096B map_ids 8
9: kprobe name probe_main_1 tag 0a87bdc2e2953b6d gpl
loaded_at 2018-05-15T04:49:52-0700 uid 0
xlated 200B not jited memlock 4096B map_ids 9
$ ps ax | grep "python ./trace.py"
21711 pts/0 T 0:03 python ./trace.py __x64_sys_write
21765 pts/0 S+ 0:00 python ./trace.py r::__x64_sys_nanosleep
21767 pts/2 S+ 0:00 python ./trace.py t:syscalls:sys_enter_nanosleep
21800 pts/3 S+ 0:00 python ./trace.py p:/home/yhs/a.out:main
22374 pts/1 S+ 0:00 grep --color=auto python ./trace.py
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-05-24 11:21:58 -07:00
|
|
|
{ "perf", do_perf },
|
tools/bpf: bpftool: add net support
Add "bpftool net" support. Networking devices are enumerated
to dump device index/name associated with xdp progs.
For each networking device, tc classes and qdiscs are enumerated
in order to check their bpf filters.
In addition, root handle and clsact ingress/egress are also checked for
bpf filters. Not all filter information is printed out. Only ifindex,
kind, filter name, prog_id and tag are printed out, which are good
enough to show attachment information. If the filter action
is a bpf action, its bpf program id, bpf name and tag will be
printed out as well.
For example,
$ ./bpftool net
xdp [
ifindex 2 devname eth0 prog_id 198
]
tc_filters [
ifindex 2 kind qdisc_htb name prefix_matcher.o:[cls_prefix_matcher_htb]
prog_id 111727 tag d08fe3b4319bc2fd act []
ifindex 2 kind qdisc_clsact_ingress name fbflow_icmp
prog_id 130246 tag 3f265c7f26db62c9 act []
ifindex 2 kind qdisc_clsact_egress name prefix_matcher.o:[cls_prefix_matcher_clsact]
prog_id 111726 tag 99a197826974c876
ifindex 2 kind qdisc_clsact_egress name cls_fg_dscp
prog_id 108619 tag dc4630674fd72dcc act []
ifindex 2 kind qdisc_clsact_egress name fbflow_egress
prog_id 130245 tag 72d2d830d6888d2c
]
$ ./bpftool -jp net
[{
"xdp": [{
"ifindex": 2,
"devname": "eth0",
"prog_id": 198
}
],
"tc_filters": [{
"ifindex": 2,
"kind": "qdisc_htb",
"name": "prefix_matcher.o:[cls_prefix_matcher_htb]",
"prog_id": 111727,
"tag": "d08fe3b4319bc2fd",
"act": []
},{
"ifindex": 2,
"kind": "qdisc_clsact_ingress",
"name": "fbflow_icmp",
"prog_id": 130246,
"tag": "3f265c7f26db62c9",
"act": []
},{
"ifindex": 2,
"kind": "qdisc_clsact_egress",
"name": "prefix_matcher.o:[cls_prefix_matcher_clsact]",
"prog_id": 111726,
"tag": "99a197826974c876"
},{
"ifindex": 2,
"kind": "qdisc_clsact_egress",
"name": "cls_fg_dscp",
"prog_id": 108619,
"tag": "dc4630674fd72dcc",
"act": []
},{
"ifindex": 2,
"kind": "qdisc_clsact_egress",
"name": "fbflow_egress",
"prog_id": 130245,
"tag": "72d2d830d6888d2c"
}
]
}
]
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-09-05 16:58:06 -07:00
|
|
|
{ "net", do_net },
|
2019-01-17 15:27:50 +00:00
|
|
|
{ "feature", do_feature },
|
2019-04-25 15:30:08 -07:00
|
|
|
{ "btf", do_btf },
|
bpftool: Add skeleton codegen command
Add `bpftool gen skeleton` command, which takes in compiled BPF .o object file
and dumps a BPF skeleton struct and related code to work with that skeleton.
Skeleton itself is tailored to a specific structure of provided BPF object
file, containing accessors (just plain struct fields) for every map and
program, as well as dedicated space for bpf_links. If BPF program is using
global variables, corresponding structure definitions of compatible memory
layout are emitted as well, making it possible to initialize and subsequently
read/update global variables values using simple and clear C syntax for
accessing fields. This skeleton majorly improves usability of
opening/loading/attaching of BPF object, as well as interacting with it
throughout the lifetime of loaded BPF object.
Generated skeleton struct has the following structure:
struct <object-name> {
/* used by libbpf's skeleton API */
struct bpf_object_skeleton *skeleton;
/* bpf_object for libbpf APIs */
struct bpf_object *obj;
struct {
/* for every defined map in BPF object: */
struct bpf_map *<map-name>;
} maps;
struct {
/* for every program in BPF object: */
struct bpf_program *<program-name>;
} progs;
struct {
/* for every program in BPF object: */
struct bpf_link *<program-name>;
} links;
/* for every present global data section: */
struct <object-name>__<one of bss, data, or rodata> {
/* memory layout of corresponding data section,
* with every defined variable represented as a struct field
* with exactly the same type, but without const/volatile
* modifiers, e.g.:
*/
int *my_var_1;
...
} *<one of bss, data, or rodata>;
};
This provides great usability improvements:
- no need to look up maps and programs by name, instead just
my_obj->maps.my_map or my_obj->progs.my_prog would give necessary
bpf_map/bpf_program pointers, which user can pass to existing libbpf APIs;
- pre-defined places for bpf_links, which will be automatically populated for
program types that libbpf knows how to attach automatically (currently
tracepoints, kprobe/kretprobe, raw tracepoint and tracing programs). On
tearing down skeleton, all active bpf_links will be destroyed (meaning BPF
programs will be detached, if they are attached). For cases in which libbpf
doesn't know how to auto-attach BPF program, user can manually create link
after loading skeleton and they will be auto-detached on skeleton
destruction:
my_obj->links.my_fancy_prog = bpf_program__attach_cgroup_whatever(
my_obj->progs.my_fancy_prog, <whatever extra param);
- it's extremely easy and convenient to work with global data from userspace
now. Both for read-only and read/write variables, it's possible to
pre-initialize them before skeleton is loaded:
skel = my_obj__open(raw_embed_data);
my_obj->rodata->my_var = 123;
my_obj__load(skel); /* 123 will be initialization value for my_var */
After load, if kernel supports mmap() for BPF arrays, user can still read
(and write for .bss and .data) variables values, but at that point it will
be directly mmap()-ed to BPF array, backing global variables. This allows to
seamlessly exchange data with BPF side. From userspace program's POV, all
the pointers and memory contents stay the same, but mapped kernel memory
changes to point to created map.
If kernel doesn't yet support mmap() for BPF arrays, it's still possible to
use those data section structs to pre-initialize .bss, .data, and .rodata,
but after load their pointers will be reset to NULL, allowing user code to
gracefully handle this condition, if necessary.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191214014341.3442258-14-andriin@fb.com
2019-12-13 17:43:37 -08:00
|
|
|
{ "gen", do_gen },
|
bpftool: Add struct_ops support
This patch adds struct_ops support to the bpftool.
To recap a bit on the recent bpf_struct_ops feature on the kernel side:
It currently supports "struct tcp_congestion_ops" to be implemented
in bpf. At a high level, bpf_struct_ops is struct_ops map populated
with a number of bpf progs. bpf_struct_ops currently supports the
"struct tcp_congestion_ops". However, the bpf_struct_ops design is
generic enough that other kernel struct ops can be supported in
the future.
Although struct_ops is map+progs at a high lever, there are differences
in details. For example,
1) After registering a struct_ops, the struct_ops is held by the kernel
subsystem (e.g. tcp-cc). Thus, there is no need to pin a
struct_ops map or its progs in order to keep them around.
2) To iterate all struct_ops in a system, it iterates all maps
in type BPF_MAP_TYPE_STRUCT_OPS. BPF_MAP_TYPE_STRUCT_OPS is
the current usual filter. In the future, it may need to
filter by other struct_ops specific properties. e.g. filter by
tcp_congestion_ops or other kernel subsystem ops in the future.
3) struct_ops requires the running kernel having BTF info. That allows
more flexibility in handling other kernel structs. e.g. it can
always dump the latest bpf_map_info.
4) Also, "struct_ops" command is not intended to repeat all features
already provided by "map" or "prog". For example, if there really
is a need to pin the struct_ops map, the user can use the "map" cmd
to do that.
While the first attempt was to reuse parts from map/prog.c, it ended up
not a lot to share. The only obvious item is the map_parse_fds() but
that still requires modifications to accommodate struct_ops map specific
filtering (for the immediate and the future needs). Together with the
earlier mentioned differences, it is better to part away from map/prog.c.
The initial set of subcmds are, register, unregister, show, and dump.
For register, it registers all struct_ops maps that can be found in an
obj file. Option can be added in the future to specify a particular
struct_ops map. Also, the common bpf_tcp_cc is stateless (e.g.
bpf_cubic.c and bpf_dctcp.c). The "reuse map" feature is not
implemented in this patch and it can be considered later also.
For other subcmds, please see the man doc for details.
A sample output of dump:
[root@arch-fb-vm1 bpf]# bpftool struct_ops dump name cubic
[{
"bpf_map_info": {
"type": 26,
"id": 64,
"key_size": 4,
"value_size": 256,
"max_entries": 1,
"map_flags": 0,
"name": "cubic",
"ifindex": 0,
"btf_vmlinux_value_type_id": 18452,
"netns_dev": 0,
"netns_ino": 0,
"btf_id": 52,
"btf_key_type_id": 0,
"btf_value_type_id": 0
}
},{
"bpf_struct_ops_tcp_congestion_ops": {
"refcnt": {
"refs": {
"counter": 1
}
},
"state": "BPF_STRUCT_OPS_STATE_INUSE",
"data": {
"list": {
"next": 0,
"prev": 0
},
"key": 0,
"flags": 0,
"init": "void (struct sock *) bictcp_init/prog_id:138",
"release": "void (struct sock *) 0",
"ssthresh": "u32 (struct sock *) bictcp_recalc_ssthresh/prog_id:141",
"cong_avoid": "void (struct sock *, u32, u32) bictcp_cong_avoid/prog_id:140",
"set_state": "void (struct sock *, u8) bictcp_state/prog_id:142",
"cwnd_event": "void (struct sock *, enum tcp_ca_event) bictcp_cwnd_event/prog_id:139",
"in_ack_event": "void (struct sock *, u32) 0",
"undo_cwnd": "u32 (struct sock *) tcp_reno_undo_cwnd/prog_id:144",
"pkts_acked": "void (struct sock *, const struct ack_sample *) bictcp_acked/prog_id:143",
"min_tso_segs": "u32 (struct sock *) 0",
"sndbuf_expand": "u32 (struct sock *) 0",
"cong_control": "void (struct sock *, const struct rate_sample *) 0",
"get_info": "size_t (struct sock *, u32, int *, union tcp_cc_info *) 0",
"name": "bpf_cubic",
"owner": 0
}
}
}
]
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20200318171656.129650-1-kafai@fb.com
2020-03-18 10:16:56 -07:00
|
|
|
{ "struct_ops", do_struct_ops },
|
2020-05-09 10:59:20 -07:00
|
|
|
{ "iter", do_iter },
|
2017-10-19 15:46:26 -07:00
|
|
|
{ "version", do_version },
|
2017-10-04 20:10:04 -07:00
|
|
|
{ 0 }
|
|
|
|
};
|
|
|
|
|
|
|
|
static int do_batch(int argc, char **argv)
|
|
|
|
{
|
2018-03-01 20:20:09 -08:00
|
|
|
char buf[BATCH_LINE_LEN_MAX], contline[BATCH_LINE_LEN_MAX];
|
|
|
|
char *n_argv[BATCH_ARG_NB_MAX];
|
2017-10-04 20:10:04 -07:00
|
|
|
unsigned int lines = 0;
|
|
|
|
int n_argc;
|
|
|
|
FILE *fp;
|
2018-03-01 20:20:08 -08:00
|
|
|
char *cp;
|
2021-03-13 13:09:18 -08:00
|
|
|
int err = 0;
|
2017-10-23 09:24:12 -07:00
|
|
|
int i;
|
2017-10-04 20:10:04 -07:00
|
|
|
|
|
|
|
if (argc < 2) {
|
2017-10-23 09:24:13 -07:00
|
|
|
p_err("too few parameters for batch");
|
2017-10-04 20:10:04 -07:00
|
|
|
return -1;
|
|
|
|
} else if (!is_prefix(*argv, "file")) {
|
2017-10-23 09:24:13 -07:00
|
|
|
p_err("expected 'file', got: %s", *argv);
|
2017-10-04 20:10:04 -07:00
|
|
|
return -1;
|
|
|
|
} else if (argc > 2) {
|
2017-10-23 09:24:13 -07:00
|
|
|
p_err("too many parameters for batch");
|
2017-10-04 20:10:04 -07:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
NEXT_ARG();
|
|
|
|
|
2018-03-01 20:20:10 -08:00
|
|
|
if (!strcmp(*argv, "-"))
|
|
|
|
fp = stdin;
|
|
|
|
else
|
|
|
|
fp = fopen(*argv, "r");
|
2017-10-04 20:10:04 -07:00
|
|
|
if (!fp) {
|
2017-10-23 09:24:13 -07:00
|
|
|
p_err("Can't open file (%s): %s", *argv, strerror(errno));
|
2017-10-04 20:10:04 -07:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2017-10-23 09:24:12 -07:00
|
|
|
if (json_output)
|
|
|
|
jsonw_start_array(json_wtr);
|
2017-10-04 20:10:04 -07:00
|
|
|
while (fgets(buf, sizeof(buf), fp)) {
|
2018-03-01 20:20:08 -08:00
|
|
|
cp = strchr(buf, '#');
|
|
|
|
if (cp)
|
|
|
|
*cp = '\0';
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
if (strlen(buf) == sizeof(buf) - 1) {
|
|
|
|
errno = E2BIG;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2018-03-01 20:20:09 -08:00
|
|
|
/* Append continuation lines if any (coming after a line ending
|
|
|
|
* with '\' in the batch file).
|
|
|
|
*/
|
|
|
|
while ((cp = strstr(buf, "\\\n")) != NULL) {
|
|
|
|
if (!fgets(contline, sizeof(contline), fp) ||
|
|
|
|
strlen(contline) == 0) {
|
|
|
|
p_err("missing continuation line on command %d",
|
|
|
|
lines);
|
|
|
|
err = -1;
|
|
|
|
goto err_close;
|
|
|
|
}
|
|
|
|
|
|
|
|
cp = strchr(contline, '#');
|
|
|
|
if (cp)
|
|
|
|
*cp = '\0';
|
|
|
|
|
|
|
|
if (strlen(buf) + strlen(contline) + 1 > sizeof(buf)) {
|
|
|
|
p_err("command %d is too long", lines);
|
|
|
|
err = -1;
|
|
|
|
goto err_close;
|
|
|
|
}
|
|
|
|
buf[strlen(buf) - 2] = '\0';
|
|
|
|
strcat(buf, contline);
|
|
|
|
}
|
|
|
|
|
2018-03-01 20:20:11 -08:00
|
|
|
n_argc = make_args(buf, n_argv, BATCH_ARG_NB_MAX, lines);
|
2017-10-04 20:10:04 -07:00
|
|
|
if (!n_argc)
|
|
|
|
continue;
|
2021-06-09 19:59:16 +08:00
|
|
|
if (n_argc < 0) {
|
|
|
|
err = n_argc;
|
2018-03-01 20:20:11 -08:00
|
|
|
goto err_close;
|
2021-06-09 19:59:16 +08:00
|
|
|
}
|
2017-10-04 20:10:04 -07:00
|
|
|
|
2017-10-23 09:24:12 -07:00
|
|
|
if (json_output) {
|
|
|
|
jsonw_start_object(json_wtr);
|
|
|
|
jsonw_name(json_wtr, "command");
|
|
|
|
jsonw_start_array(json_wtr);
|
|
|
|
for (i = 0; i < n_argc; i++)
|
|
|
|
jsonw_string(json_wtr, n_argv[i]);
|
|
|
|
jsonw_end_array(json_wtr);
|
|
|
|
jsonw_name(json_wtr, "output");
|
|
|
|
}
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
err = cmd_select(cmds, n_argc, n_argv, do_help);
|
2017-10-23 09:24:12 -07:00
|
|
|
|
|
|
|
if (json_output)
|
|
|
|
jsonw_end_object(json_wtr);
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
if (err)
|
|
|
|
goto err_close;
|
|
|
|
|
|
|
|
lines++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (errno && errno != ENOENT) {
|
2018-02-14 22:42:55 -08:00
|
|
|
p_err("reading batch file failed: %s", strerror(errno));
|
2017-10-04 20:10:04 -07:00
|
|
|
err = -1;
|
|
|
|
} else {
|
2018-10-20 23:01:49 +01:00
|
|
|
if (!json_output)
|
|
|
|
printf("processed %d commands\n", lines);
|
2017-10-04 20:10:04 -07:00
|
|
|
}
|
|
|
|
err_close:
|
2018-03-01 20:20:10 -08:00
|
|
|
if (fp != stdin)
|
|
|
|
fclose(fp);
|
2017-10-04 20:10:04 -07:00
|
|
|
|
2017-10-23 09:24:12 -07:00
|
|
|
if (json_output)
|
|
|
|
jsonw_end_array(json_wtr);
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
int main(int argc, char **argv)
|
|
|
|
{
|
2017-10-23 09:24:06 -07:00
|
|
|
static const struct option options[] = {
|
2017-10-23 09:24:07 -07:00
|
|
|
{ "json", no_argument, NULL, 'j' },
|
2017-10-23 09:24:06 -07:00
|
|
|
{ "help", no_argument, NULL, 'h' },
|
2017-10-23 09:24:07 -07:00
|
|
|
{ "pretty", no_argument, NULL, 'p' },
|
2017-10-23 09:24:06 -07:00
|
|
|
{ "version", no_argument, NULL, 'V' },
|
2017-11-08 13:55:49 +09:00
|
|
|
{ "bpffs", no_argument, NULL, 'f' },
|
2018-10-15 11:19:55 -07:00
|
|
|
{ "mapcompat", no_argument, NULL, 'm' },
|
2018-12-18 10:13:19 +00:00
|
|
|
{ "nomount", no_argument, NULL, 'n' },
|
2019-05-24 11:36:46 +01:00
|
|
|
{ "debug", no_argument, NULL, 'd' },
|
2021-05-13 17:36:19 -07:00
|
|
|
{ "use-loader", no_argument, NULL, 'L' },
|
2020-11-04 20:34:01 -08:00
|
|
|
{ "base-btf", required_argument, NULL, 'B' },
|
2021-11-10 11:23:24 -08:00
|
|
|
{ "legacy", no_argument, NULL, 'l' },
|
2017-10-23 09:24:06 -07:00
|
|
|
{ 0 }
|
|
|
|
};
|
bpftool: Add current libbpf_strict mode to version output
+ bpftool --legacy --version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool --version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --legacy --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --json --legacy version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":false,"skeletons":true}}
+ bpftool --json version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":true,"skeletons":true}}
Suggested-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20211116000448.2918854-1-sdf@google.com
2021-11-15 16:04:48 -08:00
|
|
|
bool version_requested = false;
|
2017-10-23 09:24:07 -07:00
|
|
|
int opt, ret;
|
2017-10-23 09:24:06 -07:00
|
|
|
|
2021-12-20 22:45:28 +01:00
|
|
|
setlinebuf(stdout);
|
|
|
|
|
bpftool: Clear errno after libcap's checks
When bpftool is linked against libcap, the library runs a "constructor"
function to compute the number of capabilities of the running kernel
[0], at the beginning of the execution of the program. As part of this,
it performs multiple calls to prctl(). Some of these may fail, and set
errno to a non-zero value:
# strace -e prctl ./bpftool version
prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1
prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = 1
prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
** fprintf added at the top of main(): we have errno == 1
./bpftool v7.0.0
using libbpf v1.0
features: libbfd, libbpf_strict, skeletons
+++ exited with 0 +++
This has been addressed in libcap 2.63 [1], but until this version is
available everywhere, we can fix it on bpftool side.
Let's clean errno at the beginning of the main() function, to make sure
that these checks do not interfere with the batch mode, where we error
out if errno is set after a bpftool command.
[0] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/libcap/cap_alloc.c?h=libcap-2.65#n20
[1] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=f25a1b7e69f7b33e6afb58b3e38f3450b7d2d9a0
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20220815162205.45043-1-quentin@isovalent.com
2022-08-15 17:22:05 +01:00
|
|
|
#ifdef USE_LIBCAP
|
|
|
|
/* Libcap < 2.63 hooks before main() to compute the number of
|
|
|
|
* capabilities of the running kernel, and doing so it calls prctl()
|
|
|
|
* which may fail and set errno to non-zero.
|
|
|
|
* Let's reset errno to make sure this does not interfere with the
|
|
|
|
* batch mode.
|
|
|
|
*/
|
|
|
|
errno = 0;
|
|
|
|
#endif
|
|
|
|
|
2017-10-23 09:24:06 -07:00
|
|
|
last_do_help = do_help;
|
2017-10-23 09:24:07 -07:00
|
|
|
pretty_output = false;
|
|
|
|
json_output = false;
|
2017-11-08 13:55:49 +09:00
|
|
|
show_pinned = false;
|
2018-12-18 10:13:19 +00:00
|
|
|
block_mount = false;
|
2022-10-20 11:03:00 +01:00
|
|
|
bin_name = "bpftool";
|
2017-10-23 09:24:06 -07:00
|
|
|
|
2017-11-28 17:44:30 -08:00
|
|
|
opterr = 0;
|
2021-11-10 11:23:24 -08:00
|
|
|
while ((opt = getopt_long(argc, argv, "VhpjfLmndB:l",
|
2017-10-23 09:24:06 -07:00
|
|
|
options, NULL)) >= 0) {
|
|
|
|
switch (opt) {
|
|
|
|
case 'V':
|
bpftool: Add current libbpf_strict mode to version output
+ bpftool --legacy --version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool --version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --legacy --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --json --legacy version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":false,"skeletons":true}}
+ bpftool --json version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":true,"skeletons":true}}
Suggested-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20211116000448.2918854-1-sdf@google.com
2021-11-15 16:04:48 -08:00
|
|
|
version_requested = true;
|
|
|
|
break;
|
2017-10-23 09:24:06 -07:00
|
|
|
case 'h':
|
|
|
|
return do_help(argc, argv);
|
2017-10-23 09:24:07 -07:00
|
|
|
case 'p':
|
|
|
|
pretty_output = true;
|
|
|
|
/* fall through */
|
|
|
|
case 'j':
|
2017-11-28 17:44:28 -08:00
|
|
|
if (!json_output) {
|
|
|
|
json_wtr = jsonw_new(stdout);
|
|
|
|
if (!json_wtr) {
|
|
|
|
p_err("failed to create JSON writer");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
json_output = true;
|
|
|
|
}
|
|
|
|
jsonw_pretty(json_wtr, pretty_output);
|
2017-10-23 09:24:07 -07:00
|
|
|
break;
|
2017-11-08 13:55:49 +09:00
|
|
|
case 'f':
|
|
|
|
show_pinned = true;
|
|
|
|
break;
|
2018-10-15 11:19:55 -07:00
|
|
|
case 'm':
|
2019-10-07 15:56:04 -07:00
|
|
|
relaxed_maps = true;
|
2018-10-15 11:19:55 -07:00
|
|
|
break;
|
2018-12-18 10:13:19 +00:00
|
|
|
case 'n':
|
|
|
|
block_mount = true;
|
|
|
|
break;
|
2019-05-24 11:36:46 +01:00
|
|
|
case 'd':
|
|
|
|
libbpf_set_print(print_all_levels);
|
2019-05-24 11:36:48 +01:00
|
|
|
verifier_logs = true;
|
2019-05-24 11:36:46 +01:00
|
|
|
break;
|
2020-11-04 20:34:01 -08:00
|
|
|
case 'B':
|
|
|
|
base_btf = btf__parse(optarg, NULL);
|
|
|
|
if (libbpf_get_error(base_btf)) {
|
|
|
|
p_err("failed to parse base BTF at '%s': %ld\n",
|
|
|
|
optarg, libbpf_get_error(base_btf));
|
|
|
|
base_btf = NULL;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
break;
|
2021-05-13 17:36:19 -07:00
|
|
|
case 'L':
|
|
|
|
use_loader = true;
|
|
|
|
break;
|
2021-11-10 11:23:24 -08:00
|
|
|
case 'l':
|
|
|
|
legacy_libbpf = true;
|
|
|
|
break;
|
2017-10-23 09:24:06 -07:00
|
|
|
default:
|
2017-11-28 17:44:30 -08:00
|
|
|
p_err("unrecognized option '%s'", argv[optind - 1]);
|
|
|
|
if (json_output)
|
|
|
|
clean_and_exit(-1);
|
|
|
|
else
|
|
|
|
usage();
|
2017-10-23 09:24:06 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-11-10 11:23:24 -08:00
|
|
|
if (!legacy_libbpf) {
|
2022-01-19 22:05:28 -08:00
|
|
|
/* Allow legacy map definitions for skeleton generation.
|
|
|
|
* It will still be rejected if users use LIBBPF_STRICT_ALL
|
|
|
|
* mode for loading generated skeleton.
|
|
|
|
*/
|
2022-06-10 12:26:48 +01:00
|
|
|
libbpf_set_strict_mode(LIBBPF_STRICT_ALL & ~LIBBPF_STRICT_MAP_DEFINITIONS);
|
2021-11-10 11:23:24 -08:00
|
|
|
}
|
|
|
|
|
2017-10-23 09:24:06 -07:00
|
|
|
argc -= optind;
|
|
|
|
argv += optind;
|
|
|
|
if (argc < 0)
|
|
|
|
usage();
|
2017-10-04 20:10:04 -07:00
|
|
|
|
bpftool: Add current libbpf_strict mode to version output
+ bpftool --legacy --version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool --version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --legacy --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --json --legacy version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":false,"skeletons":true}}
+ bpftool --json version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":true,"skeletons":true}}
Suggested-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20211116000448.2918854-1-sdf@google.com
2021-11-15 16:04:48 -08:00
|
|
|
if (version_requested)
|
|
|
|
return do_version(argc, argv);
|
|
|
|
|
2017-10-23 09:24:07 -07:00
|
|
|
ret = cmd_select(cmds, argc, argv, do_help);
|
|
|
|
|
|
|
|
if (json_output)
|
|
|
|
jsonw_destroy(&json_wtr);
|
|
|
|
|
2020-11-04 20:34:01 -08:00
|
|
|
btf__free(base_btf);
|
tools: bpftool: show filenames of pinned objects
Added support to show filenames of pinned objects.
For example:
root@test# ./bpftool prog
3: tracepoint name tracepoint__irq tag f677a7dd722299a3
loaded_at Oct 26/11:39 uid 0
xlated 160B not jited memlock 4096B map_ids 4
pinned /sys/fs/bpf/softirq_prog
4: tracepoint name tracepoint__irq tag ea5dc530d00b92b6
loaded_at Oct 26/11:39 uid 0
xlated 392B not jited memlock 4096B map_ids 4,6
root@test# ./bpftool --json --pretty prog
[{
"id": 3,
"type": "tracepoint",
"name": "tracepoint__irq",
"tag": "f677a7dd722299a3",
"loaded_at": "Oct 26/11:39",
"uid": 0,
"bytes_xlated": 160,
"jited": false,
"bytes_memlock": 4096,
"map_ids": [4
],
"pinned": ["/sys/fs/bpf/softirq_prog"
]
},{
"id": 4,
"type": "tracepoint",
"name": "tracepoint__irq",
"tag": "ea5dc530d00b92b6",
"loaded_at": "Oct 26/11:39",
"uid": 0,
"bytes_xlated": 392,
"jited": false,
"bytes_memlock": 4096,
"map_ids": [4,6
],
"pinned": []
}
]
root@test# ./bpftool map
4: hash name start flags 0x0
key 4B value 16B max_entries 10240 memlock 1003520B
pinned /sys/fs/bpf/softirq_map1
5: hash name iptr flags 0x0
key 4B value 8B max_entries 10240 memlock 921600B
root@test# ./bpftool --json --pretty map
[{
"id": 4,
"type": "hash",
"name": "start",
"flags": 0,
"bytes_key": 4,
"bytes_value": 16,
"max_entries": 10240,
"bytes_memlock": 1003520,
"pinned": ["/sys/fs/bpf/softirq_map1"
]
},{
"id": 5,
"type": "hash",
"name": "iptr",
"flags": 0,
"bytes_key": 4,
"bytes_value": 8,
"max_entries": 10240,
"bytes_memlock": 921600,
"pinned": []
}
]
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-08 13:55:48 +09:00
|
|
|
|
2017-10-23 09:24:07 -07:00
|
|
|
return ret;
|
2017-10-04 20:10:04 -07:00
|
|
|
}
|