kernel.git/tools/bpf/bpftool/main.c, branch linux-5.3.y

tools: bpftool: add "prog run" subcommand to test-run programs

2019-07-05T21:48:07Z

Add a new "bpftool prog run" subcommand to run a loaded program on input data (and possibly with input context) passed by the user. Print output data (and output context if relevant) into a file or into the console. Print return value and duration for the test run into the console. A "repeat" argument can be passed to run the program several times in a row. The command does not perform any kind of verification based on program type (Is this program type allowed to use an input context?) or on data consistency (Can I work with empty input data?), this is left to the kernel. Example invocation: # perl -e 'print "\x0" x 14' | ./bpftool prog run \ pinned /sys/fs/bpf/sample_ret0 \ data_in - data_out - repeat 5 0000000 0000 0000 0000 0000 0000 0000 0000 | ........ ...... Return value: 0, duration (average): 260ns When one of data_in or ctx_in is "-", bpftool reads from standard input, in binary format. Other formats (JSON, hexdump) might be supported (via an optional command line keyword like "data_fmt_in") in the future if relevant, but this would require doing more parsing in bpftool. v2: - Fix argument names for function check_single_stdin(). (Yonghong) Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Acked-by: Yonghong Song Signed-off-by: Daniel Borkmann

tools: bpftool: make -d option print debug output from verifier

2019-05-28T09:03:26Z

The "-d" option is used to require all logs available for bpftool. So far it meant telling libbpf to print even debug-level information. But there is another source of info that can be made more verbose: when we attemt to load programs with bpftool, we can pass a log_level parameter to the verifier in order to control the amount of information that is printed to the console. Reuse the "-d" option to print all information the verifier can tell. At this time, this means logs related to BPF_LOG_LEVEL1, BPF_LOG_LEVEL2 and BPF_LOG_STATS. As mentioned in the discussion on the first version of this set, these macros are internal to the kernel (include/linux/bpf_verifier.h) and are not meant to be part of the stable user API, therefore we simply use the related constants to print whatever we can at this time, without trying to tell users what is log_level1 or what is statistics. Verifier logs are only used when loading programs for now (In the future: for loading BTF objects with bpftool? Although libbpf does not currently offer to print verifier info at debug level if no error occurred when loading BTF objects), so bpftool.rst and bpftool-prog.rst are the only man pages to get the update. v3: - Add details on log level and BTF loading at the end of commit log. v2: - Remove the possibility to select the log levels to use (v1 offered a combination of "log_level1", "log_level2" and "stats"). - The macros from kernel header bpf_verifier.h are not used (and therefore not moved to UAPI header). - In v1 this was a distinct option, but is now merged in the only "-d" switch to activate libbpf and verifier debug-level logs all at the same time. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann

tools: bpftool: add -d option to get debug output from libbpf

2019-05-28T09:02:21Z

libbpf has three levels of priority for output messages: warn, info, debug. By default, debug output is not printed to the console. Add a new "--debug" (short name: "-d") option to bpftool to print libbpf logs for all three levels. Internally, we simply use the function provided by libbpf to replace the default printing function by one that prints logs regardless of their level. v2: - Remove the possibility to select the log-levels to use (v1 offered a combination of "warn", "info" and "debug"). - Rename option and offer a short name: -d|--debug. - Add option description to all bpftool manual pages (instead of bpftool-prog.rst only), as all commands use libbpf. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann

bpftool: add ability to dump BTF types

2019-04-26T04:45:14Z

Add new `btf dump` sub-command to bpftool. It allows to dump human-readable low-level BTF types representation of BTF types. BTF can be retrieved from few different sources: - from BTF object by ID; - from PROG, if it has associated BTF; - from MAP, if it has associated BTF data; it's possible to narrow down types to either key type, value type, both, or all BTF types; - from ELF file (.BTF section). Output format mostly follows BPF verifier log format with few notable exceptions: - all the type/field/param/etc names are enclosed in single quotes to allow easier grepping and to stand out a little bit more; - FUNC_PROTO output follows STRUCT/UNION/ENUM format of having one line per each argument; this is more uniform and allows easy grepping, as opposed to succinct, but inconvenient format that BPF verifier log is using. Cc: Daniel Borkmann Cc: Alexei Starovoitov Cc: Yonghong Song Cc: Martin KaFai Lau Cc: Song Liu Cc: Arnaldo Carvalho de Melo Acked-by: Yonghong Song Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov

tools: bpftool: add basic probe capability, probe syscall availability

2019-01-23T06:15:40Z

Add a new component and command for bpftool, in order to probe the system to dump a set of eBPF-related parameters so that users can know what features are available on the system. Parameters are dumped in plain or JSON output (with -j/-p options). The current patch introduces probing of one simple parameter: availability of the bpf() system call. Later commits will add other probes. Sample output: # bpftool feature probe kernel Scanning system call availability... bpf() syscall is available # bpftool --json --pretty feature probe kernel { "syscall_config": { "have_bpf_syscall": true } } The optional "kernel" keyword enforces probing of the current system, which is the only possible behaviour at this stage. It can be safely omitted. The feature comes with the relevant man page, but bash completion will come in a dedicated commit. v3: - Do not probe kernel version. Contrarily to what is written below for v2, we can have the kernel version retrieved in libbpf instead of bpftool (in the patch adding probing for program types). v2: - Remove C-style macros output from this patch. - Even though kernel version is no longer needed for testing kprobes availability, note that we still collect it in this patch so that bpftool gets able to probe (in next patches) older kernels as well. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Reviewed-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov

tools: bpftool: add an option to prevent auto-mount of bpffs, tracefs

2018-12-18T13:47:17Z

In order to make life easier for users, bpftool automatically attempts to mount the BPF virtual file system, if it is not mounted already, before trying to pin objects in it. Similarly, it attempts to mount tracefs if necessary before trying to dump the trace pipe to the console. While mounting file systems on-the-fly can improve user experience, some administrators might prefer to avoid that. Let's add an option to block these mount attempts. Note that it does not prevent automatic mounting of tracefs by debugfs for the "bpftool prog tracelog" command. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann

tools: bpftool: replace Netronome boilerplate with SPDX license headers

2018-12-13T11:08:44Z

Replace the repeated license text with SDPX identifiers. Signed-off-by: Jakub Kicinski Acked-by: Roman Gushchin Acked-by: YueHaibing Acked-by: Yonghong Song Acked-by: Stanislav Fomichev Acked-by: Sean Young Acked-by: Jiri Benc Acked-by: David Calavera Acked-by: Andrey Ignatov Acked-by: Joe Stringer Acked-by: David Ahern Acked-by: Alexei Starovoitov Acked-by: Petar Penkov Acked-by: Sandipan Das Acked-by: Prashant Bhole Acked-by: Stephen Hemminger Acked-by: John Fastabend Acked-by: Taeung Song Acked-by: Jiri Olsa Acked-by: Daniel Borkmann CC: okash.khawaja@gmail.com Signed-off-by: Daniel Borkmann

bpftool: make libbfd optional

2018-11-17T04:45:01Z

Make it possible to build bpftool without libbfd. libbfd and libopcodes are typically provided in dev/dbg packages (binutils-dev in debian) which we usually don't have installed on the fleet machines and we'd like a way to have bpftool version that works without installing any additional packages. This excludes support for disassembling jit-ted code and prints an error if the user tries to use these features. Tested by: cat > FEATURES_DUMP.bpftool < Acked-by: Jakub Kicinski Signed-off-by: Alexei Starovoitov

tools: bpftool: print nb of cmds to stdout (not stderr) for batch mode

2018-10-21T18:45:14Z

When batch mode is used and all commands succeeds, bpftool prints the number of commands processed to stderr. There is no particular reason to use stderr for this, we could as well use stdout. It would avoid getting unnecessary output on stderr if the standard ouptut is redirected, for example. Reported-by: David Beckett Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann

bpf: bpftool, add flag to allow non-compat map definitions

2018-10-15T23:13:14Z

Multiple map definition structures exist and user may have non-zero fields in their definition that are not recognized by bpftool and libbpf. The normal behavior is to then fail loading the map. Although this is a good default behavior users may still want to load the map for debugging or other reasons. This patch adds a --mapcompat flag that can be used to override the default behavior and allow loading the map even when it has additional non-zero fields. For now the only user is 'bpftool prog' we can switch over other subcommands as needed. The library exposes an API that consumes a flags field now but I kept the original API around also in case users of the API don't want to expose this. The flags field is an int in case we need more control over how the API call handles errors/features/etc in the future. Signed-off-by: John Fastabend Acked-by: Jakub Kicinski Signed-off-by: Alexei Starovoitov