2018-10-05 23:40:00 +00:00
|
|
|
/* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */
|
2018-01-30 20:55:03 +00:00
|
|
|
|
bpf tools: Introduce 'bpf' library and add bpf feature check
This is the first patch of libbpf. The goal of libbpf is to create a
standard way for accessing eBPF object files. This patch creates
'Makefile' and 'Build' for it, allows 'make' to build libbpf.a and
libbpf.so, 'make install' to put them into proper directories.
Most part of Makefile is borrowed from traceevent.
Before building, it checks the existence of libelf in Makefile, and deny
to build if not found. Instead of throwing an error if libelf not found,
the error raises in a phony target "elfdep". This design is to ensure
'make clean' still workable even if libelf is not found.
Because libbpf requires 'kern_version' field set for 'union bpf_attr'
(bpfdep" is used for that dependency), Kernel BPF API is also checked
by intruducing a new feature check 'bpf' into tools/build/feature,
which checks the existence and version of linux/bpf.h. When building
libbpf, it searches that file from include/uapi/linux in kernel source
tree (controlled by FEATURE_CHECK_CFLAGS-bpf). Since it searches kernel
source tree it reside, installing of newest kernel headers is not
required, except we are trying to port these files to an old kernel.
To avoid checking that file when perf building, the newly introduced
'bpf' feature check doesn't added into FEATURE_TESTS and
FEATURE_DISPLAY by default in tools/build/Makefile.feature, but added
into libbpf's specific.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kaixu Xia <xiakaixu@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Zefan Li <lizefan@huawei.com>
Bcc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1435716878-189507-4-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-07-01 02:13:51 +00:00
|
|
|
/*
|
|
|
|
* Common eBPF ELF object loading operations.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2013-2015 Alexei Starovoitov <ast@kernel.org>
|
|
|
|
* Copyright (C) 2015 Wang Nan <wangnan0@huawei.com>
|
|
|
|
* Copyright (C) 2015 Huawei Inc.
|
|
|
|
*/
|
2018-10-03 22:26:42 +00:00
|
|
|
#ifndef __LIBBPF_LIBBPF_H
|
|
|
|
#define __LIBBPF_LIBBPF_H
|
bpf tools: Introduce 'bpf' library and add bpf feature check
This is the first patch of libbpf. The goal of libbpf is to create a
standard way for accessing eBPF object files. This patch creates
'Makefile' and 'Build' for it, allows 'make' to build libbpf.a and
libbpf.so, 'make install' to put them into proper directories.
Most part of Makefile is borrowed from traceevent.
Before building, it checks the existence of libelf in Makefile, and deny
to build if not found. Instead of throwing an error if libelf not found,
the error raises in a phony target "elfdep". This design is to ensure
'make clean' still workable even if libelf is not found.
Because libbpf requires 'kern_version' field set for 'union bpf_attr'
(bpfdep" is used for that dependency), Kernel BPF API is also checked
by intruducing a new feature check 'bpf' into tools/build/feature,
which checks the existence and version of linux/bpf.h. When building
libbpf, it searches that file from include/uapi/linux in kernel source
tree (controlled by FEATURE_CHECK_CFLAGS-bpf). Since it searches kernel
source tree it reside, installing of newest kernel headers is not
required, except we are trying to port these files to an old kernel.
To avoid checking that file when perf building, the newly introduced
'bpf' feature check doesn't added into FEATURE_TESTS and
FEATURE_DISPLAY by default in tools/build/Makefile.feature, but added
into libbpf's specific.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kaixu Xia <xiakaixu@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Zefan Li <lizefan@huawei.com>
Bcc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1435716878-189507-4-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-07-01 02:13:51 +00:00
|
|
|
|
2019-03-11 20:07:52 +00:00
|
|
|
#include <stdarg.h>
|
2015-07-01 02:13:53 +00:00
|
|
|
#include <stdio.h>
|
2017-01-23 01:11:25 +00:00
|
|
|
#include <stdint.h>
|
2015-07-01 02:14:08 +00:00
|
|
|
#include <stdbool.h>
|
2016-11-26 07:03:27 +00:00
|
|
|
#include <sys/types.h> // for size_t
|
2017-03-31 04:45:40 +00:00
|
|
|
#include <linux/bpf.h>
|
2015-11-06 13:49:37 +00:00
|
|
|
|
2019-12-14 01:43:29 +00:00
|
|
|
#include "libbpf_common.h"
|
|
|
|
|
2018-11-21 17:29:44 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2015-11-06 13:49:37 +00:00
|
|
|
enum libbpf_errno {
|
|
|
|
__LIBBPF_ERRNO__START = 4000,
|
|
|
|
|
|
|
|
/* Something wrong in libelf */
|
|
|
|
LIBBPF_ERRNO__LIBELF = __LIBBPF_ERRNO__START,
|
|
|
|
LIBBPF_ERRNO__FORMAT, /* BPF object format invalid */
|
|
|
|
LIBBPF_ERRNO__KVERSION, /* Incorrect or no 'version' section */
|
2016-06-28 12:23:37 +00:00
|
|
|
LIBBPF_ERRNO__ENDIAN, /* Endian mismatch */
|
2015-11-06 13:49:37 +00:00
|
|
|
LIBBPF_ERRNO__INTERNAL, /* Internal error in libbpf */
|
|
|
|
LIBBPF_ERRNO__RELOC, /* Relocation failed */
|
|
|
|
LIBBPF_ERRNO__LOAD, /* Load program failure for unknown reason */
|
|
|
|
LIBBPF_ERRNO__VERIFY, /* Kernel verifier blocks program loading */
|
|
|
|
LIBBPF_ERRNO__PROG2BIG, /* Program too big */
|
|
|
|
LIBBPF_ERRNO__KVER, /* Incorrect kernel version */
|
2016-07-13 10:44:02 +00:00
|
|
|
LIBBPF_ERRNO__PROGTYPE, /* Kernel doesn't support this program type */
|
2018-01-30 20:55:01 +00:00
|
|
|
LIBBPF_ERRNO__WRNGPID, /* Wrong pid in netlink message */
|
|
|
|
LIBBPF_ERRNO__INVSEQ, /* Invalid netlink sequence */
|
tools/bpf: add more netlink functionalities in lib/bpf
This patch added a few netlink attribute parsing functions
and the netlink API functions to query networking links, tc classes,
tc qdiscs and tc filters. For example, the following API is
to get networking links:
int nl_get_link(int sock, unsigned int nl_pid,
dump_nlmsg_t dump_link_nlmsg,
void *cookie);
Note that when the API is called, the user also provided a
callback function with the following signature:
int (*dump_nlmsg_t)(void *cookie, void *msg, struct nlattr **tb);
The "cookie" is the parameter the user passed to the API and will
be available for the callback function.
The "msg" is the information about the result, e.g., ifinfomsg or
tcmsg. The "tb" is the parsed netlink attributes.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-09-05 23:58:05 +00:00
|
|
|
LIBBPF_ERRNO__NLPARSE, /* netlink parsing error */
|
2015-11-06 13:49:37 +00:00
|
|
|
__LIBBPF_ERRNO__END,
|
|
|
|
};
|
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int libbpf_strerror(int err, char *buf, size_t size);
|
2015-07-01 02:13:53 +00:00
|
|
|
|
2019-02-02 00:14:14 +00:00
|
|
|
enum libbpf_print_level {
|
|
|
|
LIBBPF_WARN,
|
|
|
|
LIBBPF_INFO,
|
|
|
|
LIBBPF_DEBUG,
|
|
|
|
};
|
|
|
|
|
2019-02-02 00:14:17 +00:00
|
|
|
typedef int (*libbpf_print_fn_t)(enum libbpf_print_level level,
|
2019-02-05 00:20:55 +00:00
|
|
|
const char *, va_list ap);
|
2015-07-01 02:13:52 +00:00
|
|
|
|
2019-07-28 03:25:26 +00:00
|
|
|
LIBBPF_API libbpf_print_fn_t libbpf_set_print(libbpf_print_fn_t fn);
|
2015-07-01 02:13:52 +00:00
|
|
|
|
2015-07-01 02:13:53 +00:00
|
|
|
/* Hide internal to user */
|
|
|
|
struct bpf_object;
|
|
|
|
|
2018-07-10 21:43:02 +00:00
|
|
|
struct bpf_object_open_attr {
|
|
|
|
const char *file;
|
|
|
|
enum bpf_prog_type prog_type;
|
|
|
|
};
|
|
|
|
|
libbpf: add bpf_object__open_{file, mem} w/ extensible opts
Add new set of bpf_object__open APIs using new approach to optional
parameters extensibility allowing simpler ABI compatibility approach.
This patch demonstrates an approach to implementing libbpf APIs that
makes it easy to extend existing APIs with extra optional parameters in
such a way, that ABI compatibility is preserved without having to do
symbol versioning and generating lots of boilerplate code to handle it.
To facilitate succinct code for working with options, add OPTS_VALID,
OPTS_HAS, and OPTS_GET macros that hide all the NULL, size, and zero
checks.
Additionally, newly added libbpf APIs are encouraged to follow similar
pattern of having all mandatory parameters as formal function parameters
and always have optional (NULL-able) xxx_opts struct, which should
always have real struct size as a first field and the rest would be
optional parameters added over time, which tune the behavior of existing
API, if specified by user.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-10-04 22:40:35 +00:00
|
|
|
struct bpf_object_open_opts {
|
|
|
|
/* size of this struct, for forward/backward compatiblity */
|
|
|
|
size_t sz;
|
|
|
|
/* object name override, if provided:
|
|
|
|
* - for object open from file, this will override setting object
|
|
|
|
* name from file path's base name;
|
|
|
|
* - for object open from memory buffer, this will specify an object
|
|
|
|
* name and will override default "<addr>-<buf-size>" name;
|
|
|
|
*/
|
|
|
|
const char *object_name;
|
|
|
|
/* parse map definitions non-strictly, allowing extra attributes/data */
|
|
|
|
bool relaxed_maps;
|
libbpf: Improve handling of failed CO-RE relocations
Previously, if libbpf failed to resolve CO-RE relocation for some
instructions, it would either return error immediately, or, if
.relaxed_core_relocs option was set, would replace relocatable offset/imm part
of an instruction with a bogus value (-1). Neither approach is good, because
there are many possible scenarios where relocation is expected to fail (e.g.,
when some field knowingly can be missing on specific kernel versions). On the
other hand, replacing offset with invalid one can hide programmer errors, if
this relocation failue wasn't anticipated.
This patch deprecates .relaxed_core_relocs option and changes the approach to
always replacing instruction, for which relocation failed, with invalid BPF
helper call instruction. For cases where this is expected, BPF program should
already ensure that that instruction is unreachable, in which case this
invalid instruction is going to be silently ignored. But if instruction wasn't
guarded, BPF program will be rejected at verification step with verifier log
pointing precisely to the place in assembly where the problem is.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20200124053837.2434679-1-andriin@fb.com
2020-01-24 05:38:37 +00:00
|
|
|
/* DEPRECATED: handle CO-RE relocations non-strictly, allowing failures.
|
|
|
|
* Value is ignored. Relocations always are processed non-strictly.
|
|
|
|
* Non-relocatable instructions are replaced with invalid ones to
|
|
|
|
* prevent accidental errors.
|
|
|
|
* */
|
2019-10-15 18:28:47 +00:00
|
|
|
bool relaxed_core_relocs;
|
2019-11-02 11:09:41 +00:00
|
|
|
/* maps that set the 'pinning' attribute in their definition will have
|
|
|
|
* their pin_path attribute set to a file in this directory, and be
|
|
|
|
* auto-pinned to that path on load; defaults to "/sys/fs/bpf".
|
|
|
|
*/
|
|
|
|
const char *pin_root_path;
|
2019-11-14 18:57:18 +00:00
|
|
|
__u32 attach_prog_fd;
|
2019-12-19 00:28:35 +00:00
|
|
|
/* Additional kernel config content that augments and overrides
|
|
|
|
* system Kconfig for CONFIG_xxx externs.
|
libbpf: Support libbpf-provided extern variables
Add support for extern variables, provided to BPF program by libbpf. Currently
the following extern variables are supported:
- LINUX_KERNEL_VERSION; version of a kernel in which BPF program is
executing, follows KERNEL_VERSION() macro convention, can be 4- and 8-byte
long;
- CONFIG_xxx values; a set of values of actual kernel config. Tristate,
boolean, strings, and integer values are supported.
Set of possible values is determined by declared type of extern variable.
Supported types of variables are:
- Tristate values. Are represented as `enum libbpf_tristate`. Accepted values
are **strictly** 'y', 'n', or 'm', which are represented as TRI_YES, TRI_NO,
or TRI_MODULE, respectively.
- Boolean values. Are represented as bool (_Bool) types. Accepted values are
'y' and 'n' only, turning into true/false values, respectively.
- Single-character values. Can be used both as a substritute for
bool/tristate, or as a small-range integer:
- 'y'/'n'/'m' are represented as is, as characters 'y', 'n', or 'm';
- integers in a range [-128, 127] or [0, 255] (depending on signedness of
char in target architecture) are recognized and represented with
respective values of char type.
- Strings. String values are declared as fixed-length char arrays. String of
up to that length will be accepted and put in first N bytes of char array,
with the rest of bytes zeroed out. If config string value is longer than
space alloted, it will be truncated and warning message emitted. Char array
is always zero terminated. String literals in config have to be enclosed in
double quotes, just like C-style string literals.
- Integers. 8-, 16-, 32-, and 64-bit integers are supported, both signed and
unsigned variants. Libbpf enforces parsed config value to be in the
supported range of corresponding integer type. Integers values in config can
be:
- decimal integers, with optional + and - signs;
- hexadecimal integers, prefixed with 0x or 0X;
- octal integers, starting with 0.
Config file itself is searched in /boot/config-$(uname -r) location with
fallback to /proc/config.gz, unless config path is specified explicitly
through bpf_object_open_opts' kernel_config_path option. Both gzipped and
plain text formats are supported. Libbpf adds explicit dependency on zlib
because of this, but this shouldn't be a problem, given libelf already depends
on zlib.
All detected extern variables, are put into a separate .extern internal map.
It, similarly to .rodata map, is marked as read-only from BPF program side, as
well as is frozen on load. This allows BPF verifier to track extern values as
constants and perform enhanced branch prediction and dead code elimination.
This can be relied upon for doing kernel version/feature detection and using
potentially unsupported field relocations or BPF helpers in a CO-RE-based BPF
program, while still having a single version of BPF program running on old and
new kernels. Selftests are validating this explicitly for unexisting BPF
helper.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20191214014710.3449601-3-andriin@fb.com
2019-12-14 01:47:08 +00:00
|
|
|
*/
|
2019-12-19 00:28:35 +00:00
|
|
|
const char *kconfig;
|
libbpf: add bpf_object__open_{file, mem} w/ extensible opts
Add new set of bpf_object__open APIs using new approach to optional
parameters extensibility allowing simpler ABI compatibility approach.
This patch demonstrates an approach to implementing libbpf APIs that
makes it easy to extend existing APIs with extra optional parameters in
such a way, that ABI compatibility is preserved without having to do
symbol versioning and generating lots of boilerplate code to handle it.
To facilitate succinct code for working with options, add OPTS_VALID,
OPTS_HAS, and OPTS_GET macros that hide all the NULL, size, and zero
checks.
Additionally, newly added libbpf APIs are encouraged to follow similar
pattern of having all mandatory parameters as formal function parameters
and always have optional (NULL-able) xxx_opts struct, which should
always have real struct size as a first field and the rest would be
optional parameters added over time, which tune the behavior of existing
API, if specified by user.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-10-04 22:40:35 +00:00
|
|
|
};
|
2019-12-19 00:28:35 +00:00
|
|
|
#define bpf_object_open_opts__last_field kconfig
|
libbpf: add bpf_object__open_{file, mem} w/ extensible opts
Add new set of bpf_object__open APIs using new approach to optional
parameters extensibility allowing simpler ABI compatibility approach.
This patch demonstrates an approach to implementing libbpf APIs that
makes it easy to extend existing APIs with extra optional parameters in
such a way, that ABI compatibility is preserved without having to do
symbol versioning and generating lots of boilerplate code to handle it.
To facilitate succinct code for working with options, add OPTS_VALID,
OPTS_HAS, and OPTS_GET macros that hide all the NULL, size, and zero
checks.
Additionally, newly added libbpf APIs are encouraged to follow similar
pattern of having all mandatory parameters as formal function parameters
and always have optional (NULL-able) xxx_opts struct, which should
always have real struct size as a first field and the rest would be
optional parameters added over time, which tune the behavior of existing
API, if specified by user.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-10-04 22:40:35 +00:00
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API struct bpf_object *bpf_object__open(const char *path);
|
|
|
|
LIBBPF_API struct bpf_object *
|
2019-12-14 01:43:32 +00:00
|
|
|
bpf_object__open_file(const char *path, const struct bpf_object_open_opts *opts);
|
libbpf: add bpf_object__open_{file, mem} w/ extensible opts
Add new set of bpf_object__open APIs using new approach to optional
parameters extensibility allowing simpler ABI compatibility approach.
This patch demonstrates an approach to implementing libbpf APIs that
makes it easy to extend existing APIs with extra optional parameters in
such a way, that ABI compatibility is preserved without having to do
symbol versioning and generating lots of boilerplate code to handle it.
To facilitate succinct code for working with options, add OPTS_VALID,
OPTS_HAS, and OPTS_GET macros that hide all the NULL, size, and zero
checks.
Additionally, newly added libbpf APIs are encouraged to follow similar
pattern of having all mandatory parameters as formal function parameters
and always have optional (NULL-able) xxx_opts struct, which should
always have real struct size as a first field and the rest would be
optional parameters added over time, which tune the behavior of existing
API, if specified by user.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-10-04 22:40:35 +00:00
|
|
|
LIBBPF_API struct bpf_object *
|
|
|
|
bpf_object__open_mem(const void *obj_buf, size_t obj_buf_sz,
|
2019-12-14 01:43:32 +00:00
|
|
|
const struct bpf_object_open_opts *opts);
|
libbpf: add bpf_object__open_{file, mem} w/ extensible opts
Add new set of bpf_object__open APIs using new approach to optional
parameters extensibility allowing simpler ABI compatibility approach.
This patch demonstrates an approach to implementing libbpf APIs that
makes it easy to extend existing APIs with extra optional parameters in
such a way, that ABI compatibility is preserved without having to do
symbol versioning and generating lots of boilerplate code to handle it.
To facilitate succinct code for working with options, add OPTS_VALID,
OPTS_HAS, and OPTS_GET macros that hide all the NULL, size, and zero
checks.
Additionally, newly added libbpf APIs are encouraged to follow similar
pattern of having all mandatory parameters as formal function parameters
and always have optional (NULL-able) xxx_opts struct, which should
always have real struct size as a first field and the rest would be
optional parameters added over time, which tune the behavior of existing
API, if specified by user.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-10-04 22:40:35 +00:00
|
|
|
|
|
|
|
/* deprecated bpf_object__open variants */
|
|
|
|
LIBBPF_API struct bpf_object *
|
|
|
|
bpf_object__open_buffer(const void *obj_buf, size_t obj_buf_sz,
|
|
|
|
const char *name);
|
|
|
|
LIBBPF_API struct bpf_object *
|
2018-10-16 05:50:34 +00:00
|
|
|
bpf_object__open_xattr(struct bpf_object_open_attr *attr);
|
libbpf: add bpf_object__open_{file, mem} w/ extensible opts
Add new set of bpf_object__open APIs using new approach to optional
parameters extensibility allowing simpler ABI compatibility approach.
This patch demonstrates an approach to implementing libbpf APIs that
makes it easy to extend existing APIs with extra optional parameters in
such a way, that ABI compatibility is preserved without having to do
symbol versioning and generating lots of boilerplate code to handle it.
To facilitate succinct code for working with options, add OPTS_VALID,
OPTS_HAS, and OPTS_GET macros that hide all the NULL, size, and zero
checks.
Additionally, newly added libbpf APIs are encouraged to follow similar
pattern of having all mandatory parameters as formal function parameters
and always have optional (NULL-able) xxx_opts struct, which should
always have real struct size as a first field and the rest would be
optional parameters added over time, which tune the behavior of existing
API, if specified by user.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-10-04 22:40:35 +00:00
|
|
|
|
2019-11-02 11:09:41 +00:00
|
|
|
enum libbpf_pin_type {
|
|
|
|
LIBBPF_PIN_NONE,
|
|
|
|
/* PIN_BY_NAME: pin maps by name (in /sys/fs/bpf by default) */
|
|
|
|
LIBBPF_PIN_BY_NAME,
|
|
|
|
};
|
|
|
|
|
2019-11-02 11:09:38 +00:00
|
|
|
/* pin_maps and unpin_maps can both be called with a NULL path, in which case
|
|
|
|
* they will use the pin_path attribute of each map (and ignore all maps that
|
|
|
|
* don't have a pin_path set).
|
|
|
|
*/
|
2018-11-09 16:21:41 +00:00
|
|
|
LIBBPF_API int bpf_object__pin_maps(struct bpf_object *obj, const char *path);
|
|
|
|
LIBBPF_API int bpf_object__unpin_maps(struct bpf_object *obj,
|
|
|
|
const char *path);
|
|
|
|
LIBBPF_API int bpf_object__pin_programs(struct bpf_object *obj,
|
|
|
|
const char *path);
|
|
|
|
LIBBPF_API int bpf_object__unpin_programs(struct bpf_object *obj,
|
|
|
|
const char *path);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_object__pin(struct bpf_object *object, const char *path);
|
|
|
|
LIBBPF_API void bpf_object__close(struct bpf_object *object);
|
2015-07-01 02:13:53 +00:00
|
|
|
|
2019-05-24 10:36:47 +00:00
|
|
|
struct bpf_object_load_attr {
|
|
|
|
struct bpf_object *obj;
|
|
|
|
int log_level;
|
2019-08-07 21:39:51 +00:00
|
|
|
const char *target_btf_path;
|
2019-05-24 10:36:47 +00:00
|
|
|
};
|
|
|
|
|
2015-07-01 02:14:04 +00:00
|
|
|
/* Load/unload object into/from kernel */
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_object__load(struct bpf_object *obj);
|
2019-05-24 10:36:47 +00:00
|
|
|
LIBBPF_API int bpf_object__load_xattr(struct bpf_object_load_attr *attr);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_object__unload(struct bpf_object *obj);
|
2019-12-14 01:43:32 +00:00
|
|
|
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API const char *bpf_object__name(const struct bpf_object *obj);
|
|
|
|
LIBBPF_API unsigned int bpf_object__kversion(const struct bpf_object *obj);
|
2021-03-23 04:09:52 +00:00
|
|
|
LIBBPF_API int bpf_object__set_kversion(struct bpf_object *obj, __u32 kern_version);
|
2019-02-14 23:01:43 +00:00
|
|
|
|
|
|
|
struct btf;
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API struct btf *bpf_object__btf(const struct bpf_object *obj);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_object__btf_fd(const struct bpf_object *obj);
|
2015-07-01 02:14:04 +00:00
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API struct bpf_program *
|
2019-06-17 22:48:58 +00:00
|
|
|
bpf_object__find_program_by_title(const struct bpf_object *obj,
|
|
|
|
const char *title);
|
2019-12-14 01:43:32 +00:00
|
|
|
LIBBPF_API struct bpf_program *
|
|
|
|
bpf_object__find_program_by_name(const struct bpf_object *obj,
|
|
|
|
const char *name);
|
2018-07-26 21:32:19 +00:00
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API struct bpf_object *bpf_object__next(struct bpf_object *prev);
|
2015-07-01 02:14:10 +00:00
|
|
|
#define bpf_object__for_each_safe(pos, tmp) \
|
|
|
|
for ((pos) = bpf_object__next(NULL), \
|
|
|
|
(tmp) = bpf_object__next(pos); \
|
|
|
|
(pos) != NULL; \
|
|
|
|
(pos) = (tmp), (tmp) = bpf_object__next(tmp))
|
|
|
|
|
2016-11-26 07:03:26 +00:00
|
|
|
typedef void (*bpf_object_clear_priv_t)(struct bpf_object *, void *);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_object__set_priv(struct bpf_object *obj, void *priv,
|
|
|
|
bpf_object_clear_priv_t clear_priv);
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API void *bpf_object__priv(const struct bpf_object *prog);
|
2016-11-26 07:03:26 +00:00
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int
|
|
|
|
libbpf_prog_type_by_name(const char *name, enum bpf_prog_type *prog_type,
|
|
|
|
enum bpf_attach_type *expected_attach_type);
|
|
|
|
LIBBPF_API int libbpf_attach_type_by_name(const char *name,
|
|
|
|
enum bpf_attach_type *attach_type);
|
2019-11-14 18:57:06 +00:00
|
|
|
LIBBPF_API int libbpf_find_vmlinux_btf_id(const char *name,
|
|
|
|
enum bpf_attach_type attach_type);
|
2018-07-10 21:42:59 +00:00
|
|
|
|
2018-05-10 17:24:41 +00:00
|
|
|
/* Accessors of bpf_program */
|
2015-07-01 02:14:08 +00:00
|
|
|
struct bpf_program;
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API struct bpf_program *bpf_program__next(struct bpf_program *prog,
|
2019-06-17 22:48:58 +00:00
|
|
|
const struct bpf_object *obj);
|
2015-07-01 02:14:08 +00:00
|
|
|
|
|
|
|
#define bpf_object__for_each_program(pos, obj) \
|
|
|
|
for ((pos) = bpf_program__next(NULL, (obj)); \
|
|
|
|
(pos) != NULL; \
|
|
|
|
(pos) = bpf_program__next((pos), (obj)))
|
|
|
|
|
2018-11-09 16:21:41 +00:00
|
|
|
LIBBPF_API struct bpf_program *bpf_program__prev(struct bpf_program *prog,
|
2019-06-17 22:48:58 +00:00
|
|
|
const struct bpf_object *obj);
|
2018-11-09 16:21:41 +00:00
|
|
|
|
2019-06-17 22:48:58 +00:00
|
|
|
typedef void (*bpf_program_clear_priv_t)(struct bpf_program *, void *);
|
2015-07-01 02:14:08 +00:00
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_program__set_priv(struct bpf_program *prog, void *priv,
|
|
|
|
bpf_program_clear_priv_t clear_priv);
|
2015-07-01 02:14:08 +00:00
|
|
|
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API void *bpf_program__priv(const struct bpf_program *prog);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API void bpf_program__set_ifindex(struct bpf_program *prog,
|
|
|
|
__u32 ifindex);
|
2015-07-01 02:14:08 +00:00
|
|
|
|
2019-12-14 01:43:32 +00:00
|
|
|
LIBBPF_API const char *bpf_program__name(const struct bpf_program *prog);
|
2020-09-03 20:35:38 +00:00
|
|
|
LIBBPF_API const char *bpf_program__section_name(const struct bpf_program *prog);
|
|
|
|
LIBBPF_API LIBBPF_DEPRECATED("BPF program title is confusing term; please use bpf_program__section_name() instead")
|
|
|
|
const char *bpf_program__title(const struct bpf_program *prog, bool needs_copy);
|
libbpf: Support disabling auto-loading BPF programs
Currently, bpf_object__load() (and by induction skeleton's load), will always
attempt to prepare, relocate, and load into kernel every single BPF program
found inside the BPF object file. This is often convenient and the right thing
to do and what users expect.
But there are plenty of cases (especially with BPF development constantly
picking up the pace), where BPF application is intended to work with old
kernels, with potentially reduced set of features. But on kernels supporting
extra features, it would like to take a full advantage of them, by employing
extra BPF program. This could be a choice of using fentry/fexit over
kprobe/kretprobe, if kernel is recent enough and is built with BTF. Or BPF
program might be providing optimized bpf_iter-based solution that user-space
might want to use, whenever available. And so on.
With libbpf and BPF CO-RE in particular, it's advantageous to not have to
maintain two separate BPF object files to achieve this. So to enable such use
cases, this patch adds ability to request not auto-loading chosen BPF
programs. In such case, libbpf won't attempt to perform relocations (which
might fail due to old kernel), won't try to resolve BTF types for
BTF-aware (tp_btf/fentry/fexit/etc) program types, because BTF might not be
present, and so on. Skeleton will also automatically skip auto-attachment step
for such not loaded BPF programs.
Overall, this feature allows to simplify development and deployment of
real-world BPF applications with complicated compatibility requirements.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200625232629.3444003-2-andriin@fb.com
2020-06-25 23:26:28 +00:00
|
|
|
LIBBPF_API bool bpf_program__autoload(const struct bpf_program *prog);
|
|
|
|
LIBBPF_API int bpf_program__set_autoload(struct bpf_program *prog, bool autoload);
|
2015-07-01 02:14:08 +00:00
|
|
|
|
2019-11-09 20:37:32 +00:00
|
|
|
/* returns program size in bytes */
|
|
|
|
LIBBPF_API size_t bpf_program__size(const struct bpf_program *prog);
|
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_program__load(struct bpf_program *prog, char *license,
|
|
|
|
__u32 kern_version);
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API int bpf_program__fd(const struct bpf_program *prog);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_program__pin_instance(struct bpf_program *prog,
|
|
|
|
const char *path,
|
|
|
|
int instance);
|
2018-11-09 16:21:41 +00:00
|
|
|
LIBBPF_API int bpf_program__unpin_instance(struct bpf_program *prog,
|
|
|
|
const char *path,
|
|
|
|
int instance);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_program__pin(struct bpf_program *prog, const char *path);
|
2018-11-09 16:21:41 +00:00
|
|
|
LIBBPF_API int bpf_program__unpin(struct bpf_program *prog, const char *path);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API void bpf_program__unload(struct bpf_program *prog);
|
2015-07-01 02:14:08 +00:00
|
|
|
|
2019-07-01 23:58:56 +00:00
|
|
|
struct bpf_link;
|
|
|
|
|
libbpf: Add bpf_link pinning/unpinning
With bpf_link abstraction supported by kernel explicitly, add
pinning/unpinning API for links. Also allow to create (open) bpf_link from BPF
FS file.
This API allows to have an "ephemeral" FD-based BPF links (like raw tracepoint
or fexit/freplace attachments) surviving user process exit, by pinning them in
a BPF FS, which is an important use case for long-running BPF programs.
As part of this, expose underlying FD for bpf_link. While legacy bpf_link's
might not have a FD associated with them (which will be expressed as
a bpf_link with fd=-1), kernel's abstraction is based around FD-based usage,
so match it closely. This, subsequently, allows to have a generic
pinning/unpinning API for generalized bpf_link. For some types of bpf_links
kernel might not support pinning, in which case bpf_link__pin() will return
error.
With FD being part of generic bpf_link, also get rid of bpf_link_fd in favor
of using vanialla bpf_link.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200303043159.323675-3-andriin@fb.com
2020-03-03 04:31:58 +00:00
|
|
|
LIBBPF_API struct bpf_link *bpf_link__open(const char *path);
|
|
|
|
LIBBPF_API int bpf_link__fd(const struct bpf_link *link);
|
|
|
|
LIBBPF_API const char *bpf_link__pin_path(const struct bpf_link *link);
|
|
|
|
LIBBPF_API int bpf_link__pin(struct bpf_link *link, const char *path);
|
|
|
|
LIBBPF_API int bpf_link__unpin(struct bpf_link *link);
|
2020-03-30 03:00:00 +00:00
|
|
|
LIBBPF_API int bpf_link__update_program(struct bpf_link *link,
|
|
|
|
struct bpf_program *prog);
|
libbpf: Add bpf_link__disconnect() API to preserve underlying BPF resource
There are cases in which BPF resource (program, map, etc) has to outlive
userspace program that "installed" it in the system in the first place.
When BPF program is attached, libbpf returns bpf_link object, which
is supposed to be destroyed after no longer necessary through
bpf_link__destroy() API. Currently, bpf_link destruction causes both automatic
detachment and frees up any resources allocated to for bpf_link in-memory
representation. This is inconvenient for the case described above because of
coupling of detachment and resource freeing.
This patch introduces bpf_link__disconnect() API call, which marks bpf_link as
disconnected from its underlying BPF resouces. This means that when bpf_link
is destroyed later, all its memory resources will be freed, but BPF resource
itself won't be detached.
This design allows to follow strict and resource-leak-free design by default,
while giving easy and straightforward way for user code to opt for keeping BPF
resource attached beyond lifetime of a bpf_link. For some BPF programs (i.e.,
FS-based tracepoints, kprobes, raw tracepoint, etc), user has to make sure to
pin BPF program to prevent kernel to automatically detach it on process exit.
This should typically be achived by pinning BPF program (or map in some cases)
in BPF FS.
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/20191218225039.2668205-1-andriin@fb.com
2019-12-18 22:50:39 +00:00
|
|
|
LIBBPF_API void bpf_link__disconnect(struct bpf_link *link);
|
2020-07-31 18:28:27 +00:00
|
|
|
LIBBPF_API int bpf_link__detach(struct bpf_link *link);
|
2019-07-01 23:58:56 +00:00
|
|
|
LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
|
|
|
|
|
2019-12-14 01:43:26 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach(struct bpf_program *prog);
|
2019-07-01 23:58:57 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_perf_event(struct bpf_program *prog, int pfd);
|
2019-07-01 23:58:58 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_kprobe(struct bpf_program *prog, bool retprobe,
|
|
|
|
const char *func_name);
|
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_uprobe(struct bpf_program *prog, bool retprobe,
|
|
|
|
pid_t pid, const char *binary_path,
|
|
|
|
size_t func_offset);
|
2019-07-01 23:58:59 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_tracepoint(struct bpf_program *prog,
|
|
|
|
const char *tp_category,
|
|
|
|
const char *tp_name);
|
2019-07-01 23:59:00 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_raw_tracepoint(struct bpf_program *prog,
|
|
|
|
const char *tp_name);
|
2019-11-14 18:57:06 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_trace(struct bpf_program *prog);
|
2020-03-29 00:43:54 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_lsm(struct bpf_program *prog);
|
2020-03-30 03:00:00 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_cgroup(struct bpf_program *prog, int cgroup_fd);
|
2020-05-31 08:28:40 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_netns(struct bpf_program *prog, int netns_fd);
|
2020-07-22 06:46:00 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_xdp(struct bpf_program *prog, int ifindex);
|
2020-09-29 12:45:53 +00:00
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_freplace(struct bpf_program *prog,
|
|
|
|
int target_fd, const char *attach_func_name);
|
2020-03-30 03:00:00 +00:00
|
|
|
|
bpf: libbpf: Add STRUCT_OPS support
This patch adds BPF STRUCT_OPS support to libbpf.
The only sec_name convention is SEC(".struct_ops") to identify the
struct_ops implemented in BPF,
e.g. To implement a tcp_congestion_ops:
SEC(".struct_ops")
struct tcp_congestion_ops dctcp = {
.init = (void *)dctcp_init, /* <-- a bpf_prog */
/* ... some more func prts ... */
.name = "bpf_dctcp",
};
Each struct_ops is defined as a global variable under SEC(".struct_ops")
as above. libbpf creates a map for each variable and the variable name
is the map's name. Multiple struct_ops is supported under
SEC(".struct_ops").
In the bpf_object__open phase, libbpf will look for the SEC(".struct_ops")
section and find out what is the btf-type the struct_ops is
implementing. Note that the btf-type here is referring to
a type in the bpf_prog.o's btf. A "struct bpf_map" is added
by bpf_object__add_map() as other maps do. It will then
collect (through SHT_REL) where are the bpf progs that the
func ptrs are referring to. No btf_vmlinux is needed in
the open phase.
In the bpf_object__load phase, the map-fields, which depend
on the btf_vmlinux, are initialized (in bpf_map__init_kern_struct_ops()).
It will also set the prog->type, prog->attach_btf_id, and
prog->expected_attach_type. Thus, the prog's properties do
not rely on its section name.
[ Currently, the bpf_prog's btf-type ==> btf_vmlinux's btf-type matching
process is as simple as: member-name match + btf-kind match + size match.
If these matching conditions fail, libbpf will reject.
The current targeting support is "struct tcp_congestion_ops" which
most of its members are function pointers.
The member ordering of the bpf_prog's btf-type can be different from
the btf_vmlinux's btf-type. ]
Then, all obj->maps are created as usual (in bpf_object__create_maps()).
Once the maps are created and prog's properties are all set,
the libbpf will proceed to load all the progs.
bpf_map__attach_struct_ops() is added to register a struct_ops
map to a kernel subsystem.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200109003514.3856730-1-kafai@fb.com
2020-01-09 00:35:14 +00:00
|
|
|
struct bpf_map;
|
2020-03-30 03:00:00 +00:00
|
|
|
|
bpf: libbpf: Add STRUCT_OPS support
This patch adds BPF STRUCT_OPS support to libbpf.
The only sec_name convention is SEC(".struct_ops") to identify the
struct_ops implemented in BPF,
e.g. To implement a tcp_congestion_ops:
SEC(".struct_ops")
struct tcp_congestion_ops dctcp = {
.init = (void *)dctcp_init, /* <-- a bpf_prog */
/* ... some more func prts ... */
.name = "bpf_dctcp",
};
Each struct_ops is defined as a global variable under SEC(".struct_ops")
as above. libbpf creates a map for each variable and the variable name
is the map's name. Multiple struct_ops is supported under
SEC(".struct_ops").
In the bpf_object__open phase, libbpf will look for the SEC(".struct_ops")
section and find out what is the btf-type the struct_ops is
implementing. Note that the btf-type here is referring to
a type in the bpf_prog.o's btf. A "struct bpf_map" is added
by bpf_object__add_map() as other maps do. It will then
collect (through SHT_REL) where are the bpf progs that the
func ptrs are referring to. No btf_vmlinux is needed in
the open phase.
In the bpf_object__load phase, the map-fields, which depend
on the btf_vmlinux, are initialized (in bpf_map__init_kern_struct_ops()).
It will also set the prog->type, prog->attach_btf_id, and
prog->expected_attach_type. Thus, the prog's properties do
not rely on its section name.
[ Currently, the bpf_prog's btf-type ==> btf_vmlinux's btf-type matching
process is as simple as: member-name match + btf-kind match + size match.
If these matching conditions fail, libbpf will reject.
The current targeting support is "struct tcp_congestion_ops" which
most of its members are function pointers.
The member ordering of the bpf_prog's btf-type can be different from
the btf_vmlinux's btf-type. ]
Then, all obj->maps are created as usual (in bpf_object__create_maps()).
Once the maps are created and prog's properties are all set,
the libbpf will proceed to load all the progs.
bpf_map__attach_struct_ops() is added to register a struct_ops
map to a kernel subsystem.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200109003514.3856730-1-kafai@fb.com
2020-01-09 00:35:14 +00:00
|
|
|
LIBBPF_API struct bpf_link *bpf_map__attach_struct_ops(struct bpf_map *map);
|
2020-03-30 03:00:00 +00:00
|
|
|
|
2020-05-09 17:59:17 +00:00
|
|
|
struct bpf_iter_attach_opts {
|
|
|
|
size_t sz; /* size of this struct for forward/backward compatibility */
|
2020-08-05 05:50:58 +00:00
|
|
|
union bpf_iter_link_info *link_info;
|
|
|
|
__u32 link_info_len;
|
2020-05-09 17:59:17 +00:00
|
|
|
};
|
2020-08-05 05:50:58 +00:00
|
|
|
#define bpf_iter_attach_opts__last_field link_info_len
|
2020-05-09 17:59:17 +00:00
|
|
|
|
|
|
|
LIBBPF_API struct bpf_link *
|
|
|
|
bpf_program__attach_iter(struct bpf_program *prog,
|
|
|
|
const struct bpf_iter_attach_opts *opts);
|
|
|
|
|
2015-11-16 12:10:09 +00:00
|
|
|
struct bpf_insn;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Libbpf allows callers to adjust BPF programs before being loaded
|
2018-05-10 17:24:41 +00:00
|
|
|
* into kernel. One program in an object file can be transformed into
|
|
|
|
* multiple variants to be attached to different hooks.
|
2015-11-16 12:10:09 +00:00
|
|
|
*
|
|
|
|
* bpf_program_prep_t, bpf_program__set_prep and bpf_program__nth_fd
|
2018-05-10 17:24:41 +00:00
|
|
|
* form an API for this purpose.
|
2015-11-16 12:10:09 +00:00
|
|
|
*
|
|
|
|
* - bpf_program_prep_t:
|
2018-05-10 17:24:41 +00:00
|
|
|
* Defines a 'preprocessor', which is a caller defined function
|
2015-11-16 12:10:09 +00:00
|
|
|
* passed to libbpf through bpf_program__set_prep(), and will be
|
|
|
|
* called before program is loaded. The processor should adjust
|
2018-05-10 17:24:41 +00:00
|
|
|
* the program one time for each instance according to the instance id
|
2015-11-16 12:10:09 +00:00
|
|
|
* passed to it.
|
|
|
|
*
|
|
|
|
* - bpf_program__set_prep:
|
2018-05-10 17:24:41 +00:00
|
|
|
* Attaches a preprocessor to a BPF program. The number of instances
|
|
|
|
* that should be created is also passed through this function.
|
2015-11-16 12:10:09 +00:00
|
|
|
*
|
|
|
|
* - bpf_program__nth_fd:
|
2018-05-10 17:24:41 +00:00
|
|
|
* After the program is loaded, get resulting FD of a given instance
|
|
|
|
* of the BPF program.
|
2015-11-16 12:10:09 +00:00
|
|
|
*
|
2018-05-10 17:24:41 +00:00
|
|
|
* If bpf_program__set_prep() is not used, the program would be loaded
|
2015-11-16 12:10:09 +00:00
|
|
|
* without adjustment during bpf_object__load(). The program has only
|
|
|
|
* one instance. In this case bpf_program__fd(prog) is equal to
|
|
|
|
* bpf_program__nth_fd(prog, 0).
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct bpf_prog_prep_result {
|
|
|
|
/*
|
|
|
|
* If not NULL, load new instruction array.
|
|
|
|
* If set to NULL, don't load this instance.
|
|
|
|
*/
|
|
|
|
struct bpf_insn *new_insn_ptr;
|
|
|
|
int new_insn_cnt;
|
|
|
|
|
2018-05-10 17:24:41 +00:00
|
|
|
/* If not NULL, result FD is written to it. */
|
2015-11-16 12:10:09 +00:00
|
|
|
int *pfd;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Parameters of bpf_program_prep_t:
|
|
|
|
* - prog: The bpf_program being loaded.
|
|
|
|
* - n: Index of instance being generated.
|
|
|
|
* - insns: BPF instructions array.
|
|
|
|
* - insns_cnt:Number of instructions in insns.
|
|
|
|
* - res: Output parameter, result of transformation.
|
|
|
|
*
|
|
|
|
* Return value:
|
2018-05-10 17:24:41 +00:00
|
|
|
* - Zero: pre-processing success.
|
|
|
|
* - Non-zero: pre-processing error, stop loading.
|
2015-11-16 12:10:09 +00:00
|
|
|
*/
|
|
|
|
typedef int (*bpf_program_prep_t)(struct bpf_program *prog, int n,
|
|
|
|
struct bpf_insn *insns, int insns_cnt,
|
|
|
|
struct bpf_prog_prep_result *res);
|
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_program__set_prep(struct bpf_program *prog, int nr_instance,
|
|
|
|
bpf_program_prep_t prep);
|
2015-11-16 12:10:09 +00:00
|
|
|
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API int bpf_program__nth_fd(const struct bpf_program *prog, int n);
|
2015-11-16 12:10:09 +00:00
|
|
|
|
2016-07-13 10:44:01 +00:00
|
|
|
/*
|
2018-05-10 17:24:41 +00:00
|
|
|
* Adjust type of BPF program. Default is kprobe.
|
2016-07-13 10:44:01 +00:00
|
|
|
*/
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_program__set_socket_filter(struct bpf_program *prog);
|
|
|
|
LIBBPF_API int bpf_program__set_tracepoint(struct bpf_program *prog);
|
|
|
|
LIBBPF_API int bpf_program__set_raw_tracepoint(struct bpf_program *prog);
|
|
|
|
LIBBPF_API int bpf_program__set_kprobe(struct bpf_program *prog);
|
2020-03-29 00:43:54 +00:00
|
|
|
LIBBPF_API int bpf_program__set_lsm(struct bpf_program *prog);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_program__set_sched_cls(struct bpf_program *prog);
|
|
|
|
LIBBPF_API int bpf_program__set_sched_act(struct bpf_program *prog);
|
|
|
|
LIBBPF_API int bpf_program__set_xdp(struct bpf_program *prog);
|
|
|
|
LIBBPF_API int bpf_program__set_perf_event(struct bpf_program *prog);
|
2019-10-30 22:32:12 +00:00
|
|
|
LIBBPF_API int bpf_program__set_tracing(struct bpf_program *prog);
|
bpf: libbpf: Add STRUCT_OPS support
This patch adds BPF STRUCT_OPS support to libbpf.
The only sec_name convention is SEC(".struct_ops") to identify the
struct_ops implemented in BPF,
e.g. To implement a tcp_congestion_ops:
SEC(".struct_ops")
struct tcp_congestion_ops dctcp = {
.init = (void *)dctcp_init, /* <-- a bpf_prog */
/* ... some more func prts ... */
.name = "bpf_dctcp",
};
Each struct_ops is defined as a global variable under SEC(".struct_ops")
as above. libbpf creates a map for each variable and the variable name
is the map's name. Multiple struct_ops is supported under
SEC(".struct_ops").
In the bpf_object__open phase, libbpf will look for the SEC(".struct_ops")
section and find out what is the btf-type the struct_ops is
implementing. Note that the btf-type here is referring to
a type in the bpf_prog.o's btf. A "struct bpf_map" is added
by bpf_object__add_map() as other maps do. It will then
collect (through SHT_REL) where are the bpf progs that the
func ptrs are referring to. No btf_vmlinux is needed in
the open phase.
In the bpf_object__load phase, the map-fields, which depend
on the btf_vmlinux, are initialized (in bpf_map__init_kern_struct_ops()).
It will also set the prog->type, prog->attach_btf_id, and
prog->expected_attach_type. Thus, the prog's properties do
not rely on its section name.
[ Currently, the bpf_prog's btf-type ==> btf_vmlinux's btf-type matching
process is as simple as: member-name match + btf-kind match + size match.
If these matching conditions fail, libbpf will reject.
The current targeting support is "struct tcp_congestion_ops" which
most of its members are function pointers.
The member ordering of the bpf_prog's btf-type can be different from
the btf_vmlinux's btf-type. ]
Then, all obj->maps are created as usual (in bpf_object__create_maps()).
Once the maps are created and prog's properties are all set,
the libbpf will proceed to load all the progs.
bpf_map__attach_struct_ops() is added to register a struct_ops
map to a kernel subsystem.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200109003514.3856730-1-kafai@fb.com
2020-01-09 00:35:14 +00:00
|
|
|
LIBBPF_API int bpf_program__set_struct_ops(struct bpf_program *prog);
|
2020-01-21 00:53:47 +00:00
|
|
|
LIBBPF_API int bpf_program__set_extension(struct bpf_program *prog);
|
2020-07-17 10:35:33 +00:00
|
|
|
LIBBPF_API int bpf_program__set_sk_lookup(struct bpf_program *prog);
|
2019-10-21 03:38:57 +00:00
|
|
|
|
2021-03-24 17:29:41 +00:00
|
|
|
LIBBPF_API enum bpf_prog_type bpf_program__get_type(const struct bpf_program *prog);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API void bpf_program__set_type(struct bpf_program *prog,
|
|
|
|
enum bpf_prog_type type);
|
2019-10-21 03:38:57 +00:00
|
|
|
|
|
|
|
LIBBPF_API enum bpf_attach_type
|
2021-03-24 17:29:41 +00:00
|
|
|
bpf_program__get_expected_attach_type(const struct bpf_program *prog);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API void
|
|
|
|
bpf_program__set_expected_attach_type(struct bpf_program *prog,
|
|
|
|
enum bpf_attach_type type);
|
|
|
|
|
2020-02-20 13:26:35 +00:00
|
|
|
LIBBPF_API int
|
|
|
|
bpf_program__set_attach_target(struct bpf_program *prog, int attach_prog_fd,
|
|
|
|
const char *attach_func_name);
|
|
|
|
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API bool bpf_program__is_socket_filter(const struct bpf_program *prog);
|
|
|
|
LIBBPF_API bool bpf_program__is_tracepoint(const struct bpf_program *prog);
|
|
|
|
LIBBPF_API bool bpf_program__is_raw_tracepoint(const struct bpf_program *prog);
|
|
|
|
LIBBPF_API bool bpf_program__is_kprobe(const struct bpf_program *prog);
|
2020-03-29 00:43:54 +00:00
|
|
|
LIBBPF_API bool bpf_program__is_lsm(const struct bpf_program *prog);
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API bool bpf_program__is_sched_cls(const struct bpf_program *prog);
|
|
|
|
LIBBPF_API bool bpf_program__is_sched_act(const struct bpf_program *prog);
|
|
|
|
LIBBPF_API bool bpf_program__is_xdp(const struct bpf_program *prog);
|
|
|
|
LIBBPF_API bool bpf_program__is_perf_event(const struct bpf_program *prog);
|
2019-10-30 22:32:12 +00:00
|
|
|
LIBBPF_API bool bpf_program__is_tracing(const struct bpf_program *prog);
|
bpf: libbpf: Add STRUCT_OPS support
This patch adds BPF STRUCT_OPS support to libbpf.
The only sec_name convention is SEC(".struct_ops") to identify the
struct_ops implemented in BPF,
e.g. To implement a tcp_congestion_ops:
SEC(".struct_ops")
struct tcp_congestion_ops dctcp = {
.init = (void *)dctcp_init, /* <-- a bpf_prog */
/* ... some more func prts ... */
.name = "bpf_dctcp",
};
Each struct_ops is defined as a global variable under SEC(".struct_ops")
as above. libbpf creates a map for each variable and the variable name
is the map's name. Multiple struct_ops is supported under
SEC(".struct_ops").
In the bpf_object__open phase, libbpf will look for the SEC(".struct_ops")
section and find out what is the btf-type the struct_ops is
implementing. Note that the btf-type here is referring to
a type in the bpf_prog.o's btf. A "struct bpf_map" is added
by bpf_object__add_map() as other maps do. It will then
collect (through SHT_REL) where are the bpf progs that the
func ptrs are referring to. No btf_vmlinux is needed in
the open phase.
In the bpf_object__load phase, the map-fields, which depend
on the btf_vmlinux, are initialized (in bpf_map__init_kern_struct_ops()).
It will also set the prog->type, prog->attach_btf_id, and
prog->expected_attach_type. Thus, the prog's properties do
not rely on its section name.
[ Currently, the bpf_prog's btf-type ==> btf_vmlinux's btf-type matching
process is as simple as: member-name match + btf-kind match + size match.
If these matching conditions fail, libbpf will reject.
The current targeting support is "struct tcp_congestion_ops" which
most of its members are function pointers.
The member ordering of the bpf_prog's btf-type can be different from
the btf_vmlinux's btf-type. ]
Then, all obj->maps are created as usual (in bpf_object__create_maps()).
Once the maps are created and prog's properties are all set,
the libbpf will proceed to load all the progs.
bpf_map__attach_struct_ops() is added to register a struct_ops
map to a kernel subsystem.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200109003514.3856730-1-kafai@fb.com
2020-01-09 00:35:14 +00:00
|
|
|
LIBBPF_API bool bpf_program__is_struct_ops(const struct bpf_program *prog);
|
2020-01-21 00:53:47 +00:00
|
|
|
LIBBPF_API bool bpf_program__is_extension(const struct bpf_program *prog);
|
2020-07-17 10:35:33 +00:00
|
|
|
LIBBPF_API bool bpf_program__is_sk_lookup(const struct bpf_program *prog);
|
2016-07-13 10:44:01 +00:00
|
|
|
|
2015-07-01 02:14:02 +00:00
|
|
|
/*
|
2018-05-10 17:24:41 +00:00
|
|
|
* No need for __attribute__((packed)), all members of 'bpf_map_def'
|
|
|
|
* are all aligned. In addition, using __attribute__((packed))
|
|
|
|
* would trigger a -Wpacked warning message, and lead to an error
|
|
|
|
* if -Werror is set.
|
2015-07-01 02:14:02 +00:00
|
|
|
*/
|
|
|
|
struct bpf_map_def {
|
|
|
|
unsigned int type;
|
|
|
|
unsigned int key_size;
|
|
|
|
unsigned int value_size;
|
|
|
|
unsigned int max_entries;
|
2017-10-05 14:41:58 +00:00
|
|
|
unsigned int map_flags;
|
2015-07-01 02:14:02 +00:00
|
|
|
};
|
|
|
|
|
2015-11-27 08:47:35 +00:00
|
|
|
/*
|
2018-05-10 17:24:41 +00:00
|
|
|
* The 'struct bpf_map' in include/linux/bpf.h is internal to the kernel,
|
|
|
|
* so no need to worry about a name clash.
|
2015-11-27 08:47:35 +00:00
|
|
|
*/
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API struct bpf_map *
|
2019-06-17 22:48:58 +00:00
|
|
|
bpf_object__find_map_by_name(const struct bpf_object *obj, const char *name);
|
2015-11-27 08:47:35 +00:00
|
|
|
|
2019-02-01 21:42:23 +00:00
|
|
|
LIBBPF_API int
|
2019-06-17 22:48:58 +00:00
|
|
|
bpf_object__find_map_fd_by_name(const struct bpf_object *obj, const char *name);
|
2019-02-01 21:42:23 +00:00
|
|
|
|
2016-11-26 07:03:27 +00:00
|
|
|
/*
|
|
|
|
* Get bpf_map through the offset of corresponding struct bpf_map_def
|
2018-05-10 17:24:41 +00:00
|
|
|
* in the BPF object file.
|
2016-11-26 07:03:27 +00:00
|
|
|
*/
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API struct bpf_map *
|
2016-11-26 07:03:27 +00:00
|
|
|
bpf_object__find_map_by_offset(struct bpf_object *obj, size_t offset);
|
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API struct bpf_map *
|
2019-06-17 22:48:58 +00:00
|
|
|
bpf_map__next(const struct bpf_map *map, const struct bpf_object *obj);
|
2019-02-28 03:04:12 +00:00
|
|
|
#define bpf_object__for_each_map(pos, obj) \
|
2015-11-27 08:47:35 +00:00
|
|
|
for ((pos) = bpf_map__next(NULL, (obj)); \
|
|
|
|
(pos) != NULL; \
|
|
|
|
(pos) = bpf_map__next((pos), (obj)))
|
2019-02-28 03:04:12 +00:00
|
|
|
#define bpf_map__for_each bpf_object__for_each_map
|
2015-11-27 08:47:35 +00:00
|
|
|
|
2018-11-09 16:21:41 +00:00
|
|
|
LIBBPF_API struct bpf_map *
|
2019-06-17 22:48:58 +00:00
|
|
|
bpf_map__prev(const struct bpf_map *map, const struct bpf_object *obj);
|
2018-11-09 16:21:41 +00:00
|
|
|
|
libbpf: Add a bunch of attribute getters/setters for map definitions
Add a bunch of getter for various aspects of BPF map. Some of these attribute
(e.g., key_size, value_size, type, etc) are available right now in struct
bpf_map_def, but this patch adds getter allowing to fetch them individually.
bpf_map_def approach isn't very scalable, when ABI stability requirements are
taken into account. It's much easier to extend libbpf and add support for new
features, when each aspect of BPF map has separate getter/setter.
Getters follow the common naming convention of not explicitly having "get" in
its name: bpf_map__type() returns map type, bpf_map__key_size() returns
key_size. Setters, though, explicitly have set in their name:
bpf_map__set_type(), bpf_map__set_key_size().
This patch ensures we now have a getter and a setter for the following
map attributes:
- type;
- max_entries;
- map_flags;
- numa_node;
- key_size;
- value_size;
- ifindex.
bpf_map__resize() enforces unnecessary restriction of max_entries > 0. It is
unnecessary, because libbpf actually supports zero max_entries for some cases
(e.g., for PERF_EVENT_ARRAY map) and treats it specially during map creation
time. To allow setting max_entries=0, new bpf_map__set_max_entries() setter is
added. bpf_map__resize()'s behavior is preserved for backwards compatibility
reasons.
Map ifindex getter is added as well. There is a setter already, but no
corresponding getter. Fix this assymetry as well. bpf_map__set_ifindex()
itself is converted from void function into error-returning one, similar to
other setters. The only error returned right now is -EBUSY, if BPF map is
already loaded and has corresponding FD.
One lacking attribute with no ability to get/set or even specify it
declaratively is numa_node. This patch fixes this gap and both adds
programmatic getter/setter, as well as adds support for numa_node field in
BTF-defined map.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/bpf/20200621062112.3006313-1-andriin@fb.com
2020-06-21 06:21:12 +00:00
|
|
|
/* get/set map FD */
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API int bpf_map__fd(const struct bpf_map *map);
|
libbpf: Add a bunch of attribute getters/setters for map definitions
Add a bunch of getter for various aspects of BPF map. Some of these attribute
(e.g., key_size, value_size, type, etc) are available right now in struct
bpf_map_def, but this patch adds getter allowing to fetch them individually.
bpf_map_def approach isn't very scalable, when ABI stability requirements are
taken into account. It's much easier to extend libbpf and add support for new
features, when each aspect of BPF map has separate getter/setter.
Getters follow the common naming convention of not explicitly having "get" in
its name: bpf_map__type() returns map type, bpf_map__key_size() returns
key_size. Setters, though, explicitly have set in their name:
bpf_map__set_type(), bpf_map__set_key_size().
This patch ensures we now have a getter and a setter for the following
map attributes:
- type;
- max_entries;
- map_flags;
- numa_node;
- key_size;
- value_size;
- ifindex.
bpf_map__resize() enforces unnecessary restriction of max_entries > 0. It is
unnecessary, because libbpf actually supports zero max_entries for some cases
(e.g., for PERF_EVENT_ARRAY map) and treats it specially during map creation
time. To allow setting max_entries=0, new bpf_map__set_max_entries() setter is
added. bpf_map__resize()'s behavior is preserved for backwards compatibility
reasons.
Map ifindex getter is added as well. There is a setter already, but no
corresponding getter. Fix this assymetry as well. bpf_map__set_ifindex()
itself is converted from void function into error-returning one, similar to
other setters. The only error returned right now is -EBUSY, if BPF map is
already loaded and has corresponding FD.
One lacking attribute with no ability to get/set or even specify it
declaratively is numa_node. This patch fixes this gap and both adds
programmatic getter/setter, as well as adds support for numa_node field in
BTF-defined map.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/bpf/20200621062112.3006313-1-andriin@fb.com
2020-06-21 06:21:12 +00:00
|
|
|
LIBBPF_API int bpf_map__reuse_fd(struct bpf_map *map, int fd);
|
|
|
|
/* get map definition */
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API const struct bpf_map_def *bpf_map__def(const struct bpf_map *map);
|
libbpf: Add a bunch of attribute getters/setters for map definitions
Add a bunch of getter for various aspects of BPF map. Some of these attribute
(e.g., key_size, value_size, type, etc) are available right now in struct
bpf_map_def, but this patch adds getter allowing to fetch them individually.
bpf_map_def approach isn't very scalable, when ABI stability requirements are
taken into account. It's much easier to extend libbpf and add support for new
features, when each aspect of BPF map has separate getter/setter.
Getters follow the common naming convention of not explicitly having "get" in
its name: bpf_map__type() returns map type, bpf_map__key_size() returns
key_size. Setters, though, explicitly have set in their name:
bpf_map__set_type(), bpf_map__set_key_size().
This patch ensures we now have a getter and a setter for the following
map attributes:
- type;
- max_entries;
- map_flags;
- numa_node;
- key_size;
- value_size;
- ifindex.
bpf_map__resize() enforces unnecessary restriction of max_entries > 0. It is
unnecessary, because libbpf actually supports zero max_entries for some cases
(e.g., for PERF_EVENT_ARRAY map) and treats it specially during map creation
time. To allow setting max_entries=0, new bpf_map__set_max_entries() setter is
added. bpf_map__resize()'s behavior is preserved for backwards compatibility
reasons.
Map ifindex getter is added as well. There is a setter already, but no
corresponding getter. Fix this assymetry as well. bpf_map__set_ifindex()
itself is converted from void function into error-returning one, similar to
other setters. The only error returned right now is -EBUSY, if BPF map is
already loaded and has corresponding FD.
One lacking attribute with no ability to get/set or even specify it
declaratively is numa_node. This patch fixes this gap and both adds
programmatic getter/setter, as well as adds support for numa_node field in
BTF-defined map.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/bpf/20200621062112.3006313-1-andriin@fb.com
2020-06-21 06:21:12 +00:00
|
|
|
/* get map name */
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API const char *bpf_map__name(const struct bpf_map *map);
|
libbpf: Add a bunch of attribute getters/setters for map definitions
Add a bunch of getter for various aspects of BPF map. Some of these attribute
(e.g., key_size, value_size, type, etc) are available right now in struct
bpf_map_def, but this patch adds getter allowing to fetch them individually.
bpf_map_def approach isn't very scalable, when ABI stability requirements are
taken into account. It's much easier to extend libbpf and add support for new
features, when each aspect of BPF map has separate getter/setter.
Getters follow the common naming convention of not explicitly having "get" in
its name: bpf_map__type() returns map type, bpf_map__key_size() returns
key_size. Setters, though, explicitly have set in their name:
bpf_map__set_type(), bpf_map__set_key_size().
This patch ensures we now have a getter and a setter for the following
map attributes:
- type;
- max_entries;
- map_flags;
- numa_node;
- key_size;
- value_size;
- ifindex.
bpf_map__resize() enforces unnecessary restriction of max_entries > 0. It is
unnecessary, because libbpf actually supports zero max_entries for some cases
(e.g., for PERF_EVENT_ARRAY map) and treats it specially during map creation
time. To allow setting max_entries=0, new bpf_map__set_max_entries() setter is
added. bpf_map__resize()'s behavior is preserved for backwards compatibility
reasons.
Map ifindex getter is added as well. There is a setter already, but no
corresponding getter. Fix this assymetry as well. bpf_map__set_ifindex()
itself is converted from void function into error-returning one, similar to
other setters. The only error returned right now is -EBUSY, if BPF map is
already loaded and has corresponding FD.
One lacking attribute with no ability to get/set or even specify it
declaratively is numa_node. This patch fixes this gap and both adds
programmatic getter/setter, as well as adds support for numa_node field in
BTF-defined map.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/bpf/20200621062112.3006313-1-andriin@fb.com
2020-06-21 06:21:12 +00:00
|
|
|
/* get/set map type */
|
|
|
|
LIBBPF_API enum bpf_map_type bpf_map__type(const struct bpf_map *map);
|
|
|
|
LIBBPF_API int bpf_map__set_type(struct bpf_map *map, enum bpf_map_type type);
|
|
|
|
/* get/set map size (max_entries) */
|
|
|
|
LIBBPF_API __u32 bpf_map__max_entries(const struct bpf_map *map);
|
|
|
|
LIBBPF_API int bpf_map__set_max_entries(struct bpf_map *map, __u32 max_entries);
|
|
|
|
LIBBPF_API int bpf_map__resize(struct bpf_map *map, __u32 max_entries);
|
|
|
|
/* get/set map flags */
|
|
|
|
LIBBPF_API __u32 bpf_map__map_flags(const struct bpf_map *map);
|
|
|
|
LIBBPF_API int bpf_map__set_map_flags(struct bpf_map *map, __u32 flags);
|
|
|
|
/* get/set map NUMA node */
|
|
|
|
LIBBPF_API __u32 bpf_map__numa_node(const struct bpf_map *map);
|
|
|
|
LIBBPF_API int bpf_map__set_numa_node(struct bpf_map *map, __u32 numa_node);
|
|
|
|
/* get/set map key size */
|
|
|
|
LIBBPF_API __u32 bpf_map__key_size(const struct bpf_map *map);
|
|
|
|
LIBBPF_API int bpf_map__set_key_size(struct bpf_map *map, __u32 size);
|
|
|
|
/* get/set map value size */
|
|
|
|
LIBBPF_API __u32 bpf_map__value_size(const struct bpf_map *map);
|
|
|
|
LIBBPF_API int bpf_map__set_value_size(struct bpf_map *map, __u32 size);
|
|
|
|
/* get map key/value BTF type IDs */
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API __u32 bpf_map__btf_key_type_id(const struct bpf_map *map);
|
|
|
|
LIBBPF_API __u32 bpf_map__btf_value_type_id(const struct bpf_map *map);
|
libbpf: Add a bunch of attribute getters/setters for map definitions
Add a bunch of getter for various aspects of BPF map. Some of these attribute
(e.g., key_size, value_size, type, etc) are available right now in struct
bpf_map_def, but this patch adds getter allowing to fetch them individually.
bpf_map_def approach isn't very scalable, when ABI stability requirements are
taken into account. It's much easier to extend libbpf and add support for new
features, when each aspect of BPF map has separate getter/setter.
Getters follow the common naming convention of not explicitly having "get" in
its name: bpf_map__type() returns map type, bpf_map__key_size() returns
key_size. Setters, though, explicitly have set in their name:
bpf_map__set_type(), bpf_map__set_key_size().
This patch ensures we now have a getter and a setter for the following
map attributes:
- type;
- max_entries;
- map_flags;
- numa_node;
- key_size;
- value_size;
- ifindex.
bpf_map__resize() enforces unnecessary restriction of max_entries > 0. It is
unnecessary, because libbpf actually supports zero max_entries for some cases
(e.g., for PERF_EVENT_ARRAY map) and treats it specially during map creation
time. To allow setting max_entries=0, new bpf_map__set_max_entries() setter is
added. bpf_map__resize()'s behavior is preserved for backwards compatibility
reasons.
Map ifindex getter is added as well. There is a setter already, but no
corresponding getter. Fix this assymetry as well. bpf_map__set_ifindex()
itself is converted from void function into error-returning one, similar to
other setters. The only error returned right now is -EBUSY, if BPF map is
already loaded and has corresponding FD.
One lacking attribute with no ability to get/set or even specify it
declaratively is numa_node. This patch fixes this gap and both adds
programmatic getter/setter, as well as adds support for numa_node field in
BTF-defined map.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/bpf/20200621062112.3006313-1-andriin@fb.com
2020-06-21 06:21:12 +00:00
|
|
|
/* get/set map if_index */
|
|
|
|
LIBBPF_API __u32 bpf_map__ifindex(const struct bpf_map *map);
|
|
|
|
LIBBPF_API int bpf_map__set_ifindex(struct bpf_map *map, __u32 ifindex);
|
2015-11-27 08:47:35 +00:00
|
|
|
|
|
|
|
typedef void (*bpf_map_clear_priv_t)(struct bpf_map *, void *);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_map__set_priv(struct bpf_map *map, void *priv,
|
|
|
|
bpf_map_clear_priv_t clear_priv);
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API void *bpf_map__priv(const struct bpf_map *map);
|
2020-03-29 13:22:52 +00:00
|
|
|
LIBBPF_API int bpf_map__set_initial_value(struct bpf_map *map,
|
|
|
|
const void *data, size_t size);
|
2019-06-17 22:48:58 +00:00
|
|
|
LIBBPF_API bool bpf_map__is_offload_neutral(const struct bpf_map *map);
|
|
|
|
LIBBPF_API bool bpf_map__is_internal(const struct bpf_map *map);
|
2019-11-02 11:09:38 +00:00
|
|
|
LIBBPF_API int bpf_map__set_pin_path(struct bpf_map *map, const char *path);
|
|
|
|
LIBBPF_API const char *bpf_map__get_pin_path(const struct bpf_map *map);
|
|
|
|
LIBBPF_API bool bpf_map__is_pinned(const struct bpf_map *map);
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_map__pin(struct bpf_map *map, const char *path);
|
2018-11-09 16:21:41 +00:00
|
|
|
LIBBPF_API int bpf_map__unpin(struct bpf_map *map, const char *path);
|
2015-11-27 08:47:35 +00:00
|
|
|
|
2018-11-21 04:55:56 +00:00
|
|
|
LIBBPF_API int bpf_map__set_inner_map_fd(struct bpf_map *map, int fd);
|
2021-04-08 06:13:08 +00:00
|
|
|
LIBBPF_API struct bpf_map *bpf_map__inner_map(struct bpf_map *map);
|
2018-11-21 04:55:56 +00:00
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API long libbpf_get_error(const void *ptr);
|
2017-01-23 01:11:25 +00:00
|
|
|
|
2018-03-30 22:08:01 +00:00
|
|
|
struct bpf_prog_load_attr {
|
|
|
|
const char *file;
|
|
|
|
enum bpf_prog_type prog_type;
|
|
|
|
enum bpf_attach_type expected_attach_type;
|
2018-05-16 21:02:49 +00:00
|
|
|
int ifindex;
|
2019-04-02 04:27:47 +00:00
|
|
|
int log_level;
|
2019-05-24 22:25:19 +00:00
|
|
|
int prog_flags;
|
2018-03-30 22:08:01 +00:00
|
|
|
};
|
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
|
|
|
|
struct bpf_object **pobj, int *prog_fd);
|
|
|
|
LIBBPF_API int bpf_prog_load(const char *file, enum bpf_prog_type type,
|
|
|
|
struct bpf_object **pobj, int *prog_fd);
|
2018-01-30 20:55:01 +00:00
|
|
|
|
2019-11-09 20:37:31 +00:00
|
|
|
struct xdp_link_info {
|
|
|
|
__u32 prog_id;
|
|
|
|
__u32 drv_prog_id;
|
|
|
|
__u32 hw_prog_id;
|
|
|
|
__u32 skb_prog_id;
|
|
|
|
__u8 attach_mode;
|
|
|
|
};
|
|
|
|
|
2020-03-25 17:23:28 +00:00
|
|
|
struct bpf_xdp_set_link_opts {
|
|
|
|
size_t sz;
|
2020-04-14 14:50:24 +00:00
|
|
|
int old_fd;
|
2021-03-13 21:09:17 +00:00
|
|
|
size_t :0;
|
2020-03-25 17:23:28 +00:00
|
|
|
};
|
|
|
|
#define bpf_xdp_set_link_opts__last_field old_fd
|
|
|
|
|
2018-10-16 05:50:34 +00:00
|
|
|
LIBBPF_API int bpf_set_link_xdp_fd(int ifindex, int fd, __u32 flags);
|
2020-03-25 17:23:28 +00:00
|
|
|
LIBBPF_API int bpf_set_link_xdp_fd_opts(int ifindex, int fd, __u32 flags,
|
|
|
|
const struct bpf_xdp_set_link_opts *opts);
|
2019-02-01 21:42:29 +00:00
|
|
|
LIBBPF_API int bpf_get_link_xdp_id(int ifindex, __u32 *prog_id, __u32 flags);
|
2019-11-09 20:37:31 +00:00
|
|
|
LIBBPF_API int bpf_get_link_xdp_info(int ifindex, struct xdp_link_info *info,
|
|
|
|
size_t info_size, __u32 flags);
|
2018-05-10 17:24:40 +00:00
|
|
|
|
libbpf: Add BPF ring buffer support
Declaring and instantiating BPF ring buffer doesn't require any changes to
libbpf, as it's just another type of maps. So using existing BTF-defined maps
syntax with __uint(type, BPF_MAP_TYPE_RINGBUF) and __uint(max_elements,
<size-of-ring-buf>) is all that's necessary to create and use BPF ring buffer.
This patch adds BPF ring buffer consumer to libbpf. It is very similar to
perf_buffer implementation in terms of API, but also attempts to fix some
minor problems and inconveniences with existing perf_buffer API.
ring_buffer support both single ring buffer use case (with just using
ring_buffer__new()), as well as allows to add more ring buffers, each with its
own callback and context. This allows to efficiently poll and consume
multiple, potentially completely independent, ring buffers, using single
epoll instance.
The latter is actually a problem in practice for applications
that are using multiple sets of perf buffers. They have to create multiple
instances for struct perf_buffer and poll them independently or in a loop,
each approach having its own problems (e.g., inability to use a common poll
timeout). struct ring_buffer eliminates this problem by aggregating many
independent ring buffer instances under the single "ring buffer manager".
Second, perf_buffer's callback can't return error, so applications that need
to stop polling due to error in data or data signalling the end, have to use
extra mechanisms to signal that polling has to stop. ring_buffer's callback
can return error, which will be passed through back to user code and can be
acted upon appropariately.
Two APIs allow to consume ring buffer data:
- ring_buffer__poll(), which will wait for data availability notification
and will consume data only from reported ring buffer(s); this API allows
to efficiently use resources by reading data only when it becomes
available;
- ring_buffer__consume(), will attempt to read new records regardless of
data availablity notification sub-system. This API is useful for cases
when lowest latency is required, in expense of burning CPU resources.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200529075424.3139988-3-andriin@fb.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-29 07:54:21 +00:00
|
|
|
/* Ring buffer APIs */
|
|
|
|
struct ring_buffer;
|
|
|
|
|
|
|
|
typedef int (*ring_buffer_sample_fn)(void *ctx, void *data, size_t size);
|
|
|
|
|
|
|
|
struct ring_buffer_opts {
|
|
|
|
size_t sz; /* size of this struct, for forward/backward compatiblity */
|
|
|
|
};
|
|
|
|
|
|
|
|
#define ring_buffer_opts__last_field sz
|
|
|
|
|
|
|
|
LIBBPF_API struct ring_buffer *
|
|
|
|
ring_buffer__new(int map_fd, ring_buffer_sample_fn sample_cb, void *ctx,
|
|
|
|
const struct ring_buffer_opts *opts);
|
|
|
|
LIBBPF_API void ring_buffer__free(struct ring_buffer *rb);
|
|
|
|
LIBBPF_API int ring_buffer__add(struct ring_buffer *rb, int map_fd,
|
|
|
|
ring_buffer_sample_fn sample_cb, void *ctx);
|
|
|
|
LIBBPF_API int ring_buffer__poll(struct ring_buffer *rb, int timeout_ms);
|
|
|
|
LIBBPF_API int ring_buffer__consume(struct ring_buffer *rb);
|
2020-12-14 11:38:12 +00:00
|
|
|
LIBBPF_API int ring_buffer__epoll_fd(const struct ring_buffer *rb);
|
libbpf: Add BPF ring buffer support
Declaring and instantiating BPF ring buffer doesn't require any changes to
libbpf, as it's just another type of maps. So using existing BTF-defined maps
syntax with __uint(type, BPF_MAP_TYPE_RINGBUF) and __uint(max_elements,
<size-of-ring-buf>) is all that's necessary to create and use BPF ring buffer.
This patch adds BPF ring buffer consumer to libbpf. It is very similar to
perf_buffer implementation in terms of API, but also attempts to fix some
minor problems and inconveniences with existing perf_buffer API.
ring_buffer support both single ring buffer use case (with just using
ring_buffer__new()), as well as allows to add more ring buffers, each with its
own callback and context. This allows to efficiently poll and consume
multiple, potentially completely independent, ring buffers, using single
epoll instance.
The latter is actually a problem in practice for applications
that are using multiple sets of perf buffers. They have to create multiple
instances for struct perf_buffer and poll them independently or in a loop,
each approach having its own problems (e.g., inability to use a common poll
timeout). struct ring_buffer eliminates this problem by aggregating many
independent ring buffer instances under the single "ring buffer manager".
Second, perf_buffer's callback can't return error, so applications that need
to stop polling due to error in data or data signalling the end, have to use
extra mechanisms to signal that polling has to stop. ring_buffer's callback
can return error, which will be passed through back to user code and can be
acted upon appropariately.
Two APIs allow to consume ring buffer data:
- ring_buffer__poll(), which will wait for data availability notification
and will consume data only from reported ring buffer(s); this API allows
to efficiently use resources by reading data only when it becomes
available;
- ring_buffer__consume(), will attempt to read new records regardless of
data availablity notification sub-system. This API is useful for cases
when lowest latency is required, in expense of burning CPU resources.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200529075424.3139988-3-andriin@fb.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-29 07:54:21 +00:00
|
|
|
|
|
|
|
/* Perf buffer APIs */
|
2019-07-06 18:06:24 +00:00
|
|
|
struct perf_buffer;
|
|
|
|
|
|
|
|
typedef void (*perf_buffer_sample_fn)(void *ctx, int cpu,
|
|
|
|
void *data, __u32 size);
|
|
|
|
typedef void (*perf_buffer_lost_fn)(void *ctx, int cpu, __u64 cnt);
|
|
|
|
|
|
|
|
/* common use perf buffer options */
|
|
|
|
struct perf_buffer_opts {
|
|
|
|
/* if specified, sample_cb is called for each sample */
|
|
|
|
perf_buffer_sample_fn sample_cb;
|
|
|
|
/* if specified, lost_cb is called for each batch of lost samples */
|
|
|
|
perf_buffer_lost_fn lost_cb;
|
|
|
|
/* ctx is provided to sample_cb and lost_cb */
|
|
|
|
void *ctx;
|
|
|
|
};
|
|
|
|
|
|
|
|
LIBBPF_API struct perf_buffer *
|
|
|
|
perf_buffer__new(int map_fd, size_t page_cnt,
|
|
|
|
const struct perf_buffer_opts *opts);
|
|
|
|
|
2018-05-10 17:24:40 +00:00
|
|
|
enum bpf_perf_event_ret {
|
|
|
|
LIBBPF_PERF_EVENT_DONE = 0,
|
|
|
|
LIBBPF_PERF_EVENT_ERROR = -1,
|
|
|
|
LIBBPF_PERF_EVENT_CONT = -2,
|
|
|
|
};
|
|
|
|
|
2018-10-21 00:09:28 +00:00
|
|
|
struct perf_event_header;
|
2019-07-06 18:06:24 +00:00
|
|
|
|
|
|
|
typedef enum bpf_perf_event_ret
|
|
|
|
(*perf_buffer_event_fn)(void *ctx, int cpu, struct perf_event_header *event);
|
|
|
|
|
|
|
|
/* raw perf buffer options, giving most power and control */
|
|
|
|
struct perf_buffer_raw_opts {
|
|
|
|
/* perf event attrs passed directly into perf_event_open() */
|
|
|
|
struct perf_event_attr *attr;
|
|
|
|
/* raw event callback */
|
|
|
|
perf_buffer_event_fn event_cb;
|
|
|
|
/* ctx is provided to event_cb */
|
|
|
|
void *ctx;
|
|
|
|
/* if cpu_cnt == 0, open all on all possible CPUs (up to the number of
|
|
|
|
* max_entries of given PERF_EVENT_ARRAY map)
|
|
|
|
*/
|
|
|
|
int cpu_cnt;
|
|
|
|
/* if cpu_cnt > 0, cpus is an array of CPUs to open ring buffers on */
|
|
|
|
int *cpus;
|
|
|
|
/* if cpu_cnt > 0, map_keys specify map keys to set per-CPU FDs for */
|
|
|
|
int *map_keys;
|
|
|
|
};
|
|
|
|
|
|
|
|
LIBBPF_API struct perf_buffer *
|
|
|
|
perf_buffer__new_raw(int map_fd, size_t page_cnt,
|
|
|
|
const struct perf_buffer_raw_opts *opts);
|
|
|
|
|
|
|
|
LIBBPF_API void perf_buffer__free(struct perf_buffer *pb);
|
libbpf: Add perf_buffer APIs for better integration with outside epoll loop
Add a set of APIs to perf_buffer manage to allow applications to integrate
perf buffer polling into existing epoll-based infrastructure. One example is
applications using libevent already and wanting to plug perf_buffer polling,
instead of relying on perf_buffer__poll() and waste an extra thread to do it.
But perf_buffer is still extremely useful to set up and consume perf buffer
rings even for such use cases.
So to accomodate such new use cases, add three new APIs:
- perf_buffer__buffer_cnt() returns number of per-CPU buffers maintained by
given instance of perf_buffer manager;
- perf_buffer__buffer_fd() returns FD of perf_event corresponding to
a specified per-CPU buffer; this FD is then polled independently;
- perf_buffer__consume_buffer() consumes data from single per-CPU buffer,
identified by its slot index.
To support a simpler, but less efficient, way to integrate perf_buffer into
external polling logic, also expose underlying epoll FD through
perf_buffer__epoll_fd() API. It will need to be followed by
perf_buffer__poll(), wasting extra syscall, or perf_buffer__consume(), wasting
CPU to iterate buffers with no data. But could be simpler and more convenient
for some cases.
These APIs allow for great flexiblity, but do not sacrifice general usability
of perf_buffer.
Also exercise and check new APIs in perf_buffer selftest.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Link: https://lore.kernel.org/bpf/20200821165927.849538-1-andriin@fb.com
2020-08-21 16:59:27 +00:00
|
|
|
LIBBPF_API int perf_buffer__epoll_fd(const struct perf_buffer *pb);
|
2019-07-06 18:06:24 +00:00
|
|
|
LIBBPF_API int perf_buffer__poll(struct perf_buffer *pb, int timeout_ms);
|
2020-05-26 09:21:42 +00:00
|
|
|
LIBBPF_API int perf_buffer__consume(struct perf_buffer *pb);
|
libbpf: Add perf_buffer APIs for better integration with outside epoll loop
Add a set of APIs to perf_buffer manage to allow applications to integrate
perf buffer polling into existing epoll-based infrastructure. One example is
applications using libevent already and wanting to plug perf_buffer polling,
instead of relying on perf_buffer__poll() and waste an extra thread to do it.
But perf_buffer is still extremely useful to set up and consume perf buffer
rings even for such use cases.
So to accomodate such new use cases, add three new APIs:
- perf_buffer__buffer_cnt() returns number of per-CPU buffers maintained by
given instance of perf_buffer manager;
- perf_buffer__buffer_fd() returns FD of perf_event corresponding to
a specified per-CPU buffer; this FD is then polled independently;
- perf_buffer__consume_buffer() consumes data from single per-CPU buffer,
identified by its slot index.
To support a simpler, but less efficient, way to integrate perf_buffer into
external polling logic, also expose underlying epoll FD through
perf_buffer__epoll_fd() API. It will need to be followed by
perf_buffer__poll(), wasting extra syscall, or perf_buffer__consume(), wasting
CPU to iterate buffers with no data. But could be simpler and more convenient
for some cases.
These APIs allow for great flexiblity, but do not sacrifice general usability
of perf_buffer.
Also exercise and check new APIs in perf_buffer selftest.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Link: https://lore.kernel.org/bpf/20200821165927.849538-1-andriin@fb.com
2020-08-21 16:59:27 +00:00
|
|
|
LIBBPF_API int perf_buffer__consume_buffer(struct perf_buffer *pb, size_t buf_idx);
|
|
|
|
LIBBPF_API size_t perf_buffer__buffer_cnt(const struct perf_buffer *pb);
|
|
|
|
LIBBPF_API int perf_buffer__buffer_fd(const struct perf_buffer *pb, size_t buf_idx);
|
2019-07-06 18:06:24 +00:00
|
|
|
|
2018-10-21 00:09:28 +00:00
|
|
|
typedef enum bpf_perf_event_ret
|
|
|
|
(*bpf_perf_event_print_t)(struct perf_event_header *hdr,
|
|
|
|
void *private_data);
|
|
|
|
LIBBPF_API enum bpf_perf_event_ret
|
|
|
|
bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
|
|
|
|
void **copy_mem, size_t *copy_size,
|
|
|
|
bpf_perf_event_print_t fn, void *private_data);
|
tools/bpf: add more netlink functionalities in lib/bpf
This patch added a few netlink attribute parsing functions
and the netlink API functions to query networking links, tc classes,
tc qdiscs and tc filters. For example, the following API is
to get networking links:
int nl_get_link(int sock, unsigned int nl_pid,
dump_nlmsg_t dump_link_nlmsg,
void *cookie);
Note that when the API is called, the user also provided a
callback function with the following signature:
int (*dump_nlmsg_t)(void *cookie, void *msg, struct nlattr **tb);
The "cookie" is the parameter the user passed to the API and will
be available for the callback function.
The "msg" is the information about the result, e.g., ifinfomsg or
tcmsg. The "tb" is the parsed netlink attributes.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-09-05 23:58:05 +00:00
|
|
|
|
bpf: libbpf: bpftool: Print bpf_line_info during prog dump
This patch adds print bpf_line_info function in 'prog dump jitted'
and 'prog dump xlated':
[root@arch-fb-vm1 bpf]# ~/devshare/fb-kernel/linux/tools/bpf/bpftool/bpftool prog dump jited pinned /sys/fs/bpf/test_btf_haskv
[...]
int test_long_fname_2(struct dummy_tracepoint_args * arg):
bpf_prog_44a040bf25481309_test_long_fname_2:
; static int test_long_fname_2(struct dummy_tracepoint_args *arg)
0: push %rbp
1: mov %rsp,%rbp
4: sub $0x30,%rsp
b: sub $0x28,%rbp
f: mov %rbx,0x0(%rbp)
13: mov %r13,0x8(%rbp)
17: mov %r14,0x10(%rbp)
1b: mov %r15,0x18(%rbp)
1f: xor %eax,%eax
21: mov %rax,0x20(%rbp)
25: xor %esi,%esi
; int key = 0;
27: mov %esi,-0x4(%rbp)
; if (!arg->sock)
2a: mov 0x8(%rdi),%rdi
; if (!arg->sock)
2e: cmp $0x0,%rdi
32: je 0x0000000000000070
34: mov %rbp,%rsi
; counts = bpf_map_lookup_elem(&btf_map, &key);
37: add $0xfffffffffffffffc,%rsi
3b: movabs $0xffff8881139d7480,%rdi
45: add $0x110,%rdi
4c: mov 0x0(%rsi),%eax
4f: cmp $0x4,%rax
53: jae 0x000000000000005e
55: shl $0x3,%rax
59: add %rdi,%rax
5c: jmp 0x0000000000000060
5e: xor %eax,%eax
; if (!counts)
60: cmp $0x0,%rax
64: je 0x0000000000000070
; counts->v6++;
66: mov 0x4(%rax),%edi
69: add $0x1,%rdi
6d: mov %edi,0x4(%rax)
70: mov 0x0(%rbp),%rbx
74: mov 0x8(%rbp),%r13
78: mov 0x10(%rbp),%r14
7c: mov 0x18(%rbp),%r15
80: add $0x28,%rbp
84: leaveq
85: retq
[...]
With linum:
[root@arch-fb-vm1 bpf]# ~/devshare/fb-kernel/linux/tools/bpf/bpftool/bpftool prog dump jited pinned /sys/fs/bpf/test_btf_haskv linum
int _dummy_tracepoint(struct dummy_tracepoint_args * arg):
bpf_prog_b07ccb89267cf242__dummy_tracepoint:
; return test_long_fname_1(arg); [file:/data/users/kafai/fb-kernel/linux/tools/testing/selftests/bpf/test_btf_haskv.c line_num:54 line_col:9]
0: push %rbp
1: mov %rsp,%rbp
4: sub $0x28,%rsp
b: sub $0x28,%rbp
f: mov %rbx,0x0(%rbp)
13: mov %r13,0x8(%rbp)
17: mov %r14,0x10(%rbp)
1b: mov %r15,0x18(%rbp)
1f: xor %eax,%eax
21: mov %rax,0x20(%rbp)
25: callq 0x000000000000851e
; return test_long_fname_1(arg); [file:/data/users/kafai/fb-kernel/linux/tools/testing/selftests/bpf/test_btf_haskv.c line_num:54 line_col:2]
2a: xor %eax,%eax
2c: mov 0x0(%rbp),%rbx
30: mov 0x8(%rbp),%r13
34: mov 0x10(%rbp),%r14
38: mov 0x18(%rbp),%r15
3c: add $0x28,%rbp
40: leaveq
41: retq
[...]
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-12-08 00:42:32 +00:00
|
|
|
struct bpf_prog_linfo;
|
|
|
|
struct bpf_prog_info;
|
|
|
|
|
|
|
|
LIBBPF_API void bpf_prog_linfo__free(struct bpf_prog_linfo *prog_linfo);
|
|
|
|
LIBBPF_API struct bpf_prog_linfo *
|
|
|
|
bpf_prog_linfo__new(const struct bpf_prog_info *info);
|
|
|
|
LIBBPF_API const struct bpf_line_info *
|
|
|
|
bpf_prog_linfo__lfind_addr_func(const struct bpf_prog_linfo *prog_linfo,
|
|
|
|
__u64 addr, __u32 func_idx, __u32 nr_skip);
|
|
|
|
LIBBPF_API const struct bpf_line_info *
|
|
|
|
bpf_prog_linfo__lfind(const struct bpf_prog_linfo *prog_linfo,
|
|
|
|
__u32 insn_off, __u32 nr_skip);
|
|
|
|
|
2019-01-17 15:27:53 +00:00
|
|
|
/*
|
|
|
|
* Probe for supported system features
|
|
|
|
*
|
|
|
|
* Note that running many of these probes in a short amount of time can cause
|
|
|
|
* the kernel to reach the maximal size of lockable memory allowed for the
|
|
|
|
* user, causing subsequent probes to fail. In this case, the caller may want
|
|
|
|
* to adjust that limit with setrlimit().
|
|
|
|
*/
|
|
|
|
LIBBPF_API bool bpf_probe_prog_type(enum bpf_prog_type prog_type,
|
|
|
|
__u32 ifindex);
|
2019-01-17 15:27:54 +00:00
|
|
|
LIBBPF_API bool bpf_probe_map_type(enum bpf_map_type map_type, __u32 ifindex);
|
tools: bpftool: add probes for eBPF helper functions
Similarly to what was done for program types and map types, add a set of
probes to test the availability of the different eBPF helper functions
on the current system.
For each known program type, all known helpers are tested, in order to
establish a compatibility matrix. Output is provided as a set of lists
of available helpers, one per program type.
Sample output:
# bpftool feature probe kernel
...
Scanning eBPF helper functions...
eBPF helpers supported for program type socket_filter:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
eBPF helpers supported for program type kprobe:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
# bpftool --json --pretty feature probe kernel
{
...
"helpers": {
"socket_filter_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
"kprobe_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
...
}
}
v5:
- In libbpf.map, move global symbol to the new LIBBPF_0.0.2 section.
v4:
- Use "enum bpf_func_id" instead of "__u32" in bpf_probe_helper()
declaration for the type of the argument used to pass the id of
the helper to probe.
- Undef BPF_HELPER_MAKE_ENTRY after using it.
v3:
- Do not pass kernel version from bpftool to libbpf probes (kernel
version for testing program with kprobes is retrieved directly from
libbpf).
- Dump one list of available helpers per program type (instead of one
list of compatible program types per helper).
v2:
- Move probes from bpftool to libbpf.
- Test all program types for each helper, print a list of working prog
types for each helper.
- Fall back on include/uapi/linux/bpf.h for names and ids of helpers.
- Remove C-style macros output from this patch.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:55 +00:00
|
|
|
LIBBPF_API bool bpf_probe_helper(enum bpf_func_id id,
|
|
|
|
enum bpf_prog_type prog_type, __u32 ifindex);
|
2020-01-08 16:23:52 +00:00
|
|
|
LIBBPF_API bool bpf_probe_large_insn_limit(__u32 ifindex);
|
2019-01-17 15:27:53 +00:00
|
|
|
|
2019-03-12 05:30:38 +00:00
|
|
|
/*
|
|
|
|
* Get bpf_prog_info in continuous memory
|
|
|
|
*
|
|
|
|
* struct bpf_prog_info has multiple arrays. The user has option to choose
|
|
|
|
* arrays to fetch from kernel. The following APIs provide an uniform way to
|
|
|
|
* fetch these data. All arrays in bpf_prog_info are stored in a single
|
|
|
|
* continuous memory region. This makes it easy to store the info in a
|
|
|
|
* file.
|
|
|
|
*
|
|
|
|
* Before writing bpf_prog_info_linear to files, it is necessary to
|
|
|
|
* translate pointers in bpf_prog_info to offsets. Helper functions
|
|
|
|
* bpf_program__bpil_addr_to_offs() and bpf_program__bpil_offs_to_addr()
|
|
|
|
* are introduced to switch between pointers and offsets.
|
|
|
|
*
|
|
|
|
* Examples:
|
|
|
|
* # To fetch map_ids and prog_tags:
|
|
|
|
* __u64 arrays = (1UL << BPF_PROG_INFO_MAP_IDS) |
|
|
|
|
* (1UL << BPF_PROG_INFO_PROG_TAGS);
|
|
|
|
* struct bpf_prog_info_linear *info_linear =
|
|
|
|
* bpf_program__get_prog_info_linear(fd, arrays);
|
|
|
|
*
|
|
|
|
* # To save data in file
|
|
|
|
* bpf_program__bpil_addr_to_offs(info_linear);
|
|
|
|
* write(f, info_linear, sizeof(*info_linear) + info_linear->data_len);
|
|
|
|
*
|
|
|
|
* # To read data from file
|
|
|
|
* read(f, info_linear, <proper_size>);
|
|
|
|
* bpf_program__bpil_offs_to_addr(info_linear);
|
|
|
|
*/
|
|
|
|
enum bpf_prog_info_array {
|
|
|
|
BPF_PROG_INFO_FIRST_ARRAY = 0,
|
|
|
|
BPF_PROG_INFO_JITED_INSNS = 0,
|
|
|
|
BPF_PROG_INFO_XLATED_INSNS,
|
|
|
|
BPF_PROG_INFO_MAP_IDS,
|
|
|
|
BPF_PROG_INFO_JITED_KSYMS,
|
|
|
|
BPF_PROG_INFO_JITED_FUNC_LENS,
|
|
|
|
BPF_PROG_INFO_FUNC_INFO,
|
|
|
|
BPF_PROG_INFO_LINE_INFO,
|
|
|
|
BPF_PROG_INFO_JITED_LINE_INFO,
|
|
|
|
BPF_PROG_INFO_PROG_TAGS,
|
|
|
|
BPF_PROG_INFO_LAST_ARRAY,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct bpf_prog_info_linear {
|
|
|
|
/* size of struct bpf_prog_info, when the tool is compiled */
|
|
|
|
__u32 info_len;
|
|
|
|
/* total bytes allocated for data, round up to 8 bytes */
|
|
|
|
__u32 data_len;
|
|
|
|
/* which arrays are included in data */
|
|
|
|
__u64 arrays;
|
|
|
|
struct bpf_prog_info info;
|
|
|
|
__u8 data[];
|
|
|
|
};
|
|
|
|
|
|
|
|
LIBBPF_API struct bpf_prog_info_linear *
|
|
|
|
bpf_program__get_prog_info_linear(int fd, __u64 arrays);
|
|
|
|
|
|
|
|
LIBBPF_API void
|
|
|
|
bpf_program__bpil_addr_to_offs(struct bpf_prog_info_linear *info_linear);
|
|
|
|
|
|
|
|
LIBBPF_API void
|
|
|
|
bpf_program__bpil_offs_to_addr(struct bpf_prog_info_linear *info_linear);
|
|
|
|
|
2019-06-11 00:56:50 +00:00
|
|
|
/*
|
|
|
|
* A helper function to get the number of possible CPUs before looking up
|
|
|
|
* per-CPU maps. Negative errno is returned on failure.
|
|
|
|
*
|
|
|
|
* Example usage:
|
|
|
|
*
|
|
|
|
* int ncpus = libbpf_num_possible_cpus();
|
|
|
|
* if (ncpus < 0) {
|
|
|
|
* // error handling
|
|
|
|
* }
|
|
|
|
* long values[ncpus];
|
|
|
|
* bpf_map_lookup_elem(per_cpu_map_fd, key, values);
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
LIBBPF_API int libbpf_num_possible_cpus(void);
|
|
|
|
|
2019-12-14 01:43:36 +00:00
|
|
|
struct bpf_map_skeleton {
|
|
|
|
const char *name;
|
|
|
|
struct bpf_map **map;
|
|
|
|
void **mmaped;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct bpf_prog_skeleton {
|
|
|
|
const char *name;
|
|
|
|
struct bpf_program **prog;
|
|
|
|
struct bpf_link **link;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct bpf_object_skeleton {
|
|
|
|
size_t sz; /* size of this struct, for forward/backward compatibility */
|
|
|
|
|
|
|
|
const char *name;
|
|
|
|
void *data;
|
|
|
|
size_t data_sz;
|
|
|
|
|
|
|
|
struct bpf_object **obj;
|
|
|
|
|
|
|
|
int map_cnt;
|
|
|
|
int map_skel_sz; /* sizeof(struct bpf_skeleton_map) */
|
|
|
|
struct bpf_map_skeleton *maps;
|
|
|
|
|
|
|
|
int prog_cnt;
|
|
|
|
int prog_skel_sz; /* sizeof(struct bpf_skeleton_prog) */
|
|
|
|
struct bpf_prog_skeleton *progs;
|
|
|
|
};
|
|
|
|
|
|
|
|
LIBBPF_API int
|
|
|
|
bpf_object__open_skeleton(struct bpf_object_skeleton *s,
|
|
|
|
const struct bpf_object_open_opts *opts);
|
|
|
|
LIBBPF_API int bpf_object__load_skeleton(struct bpf_object_skeleton *s);
|
|
|
|
LIBBPF_API int bpf_object__attach_skeleton(struct bpf_object_skeleton *s);
|
|
|
|
LIBBPF_API void bpf_object__detach_skeleton(struct bpf_object_skeleton *s);
|
|
|
|
LIBBPF_API void bpf_object__destroy_skeleton(struct bpf_object_skeleton *s);
|
|
|
|
|
libbpf: Support libbpf-provided extern variables
Add support for extern variables, provided to BPF program by libbpf. Currently
the following extern variables are supported:
- LINUX_KERNEL_VERSION; version of a kernel in which BPF program is
executing, follows KERNEL_VERSION() macro convention, can be 4- and 8-byte
long;
- CONFIG_xxx values; a set of values of actual kernel config. Tristate,
boolean, strings, and integer values are supported.
Set of possible values is determined by declared type of extern variable.
Supported types of variables are:
- Tristate values. Are represented as `enum libbpf_tristate`. Accepted values
are **strictly** 'y', 'n', or 'm', which are represented as TRI_YES, TRI_NO,
or TRI_MODULE, respectively.
- Boolean values. Are represented as bool (_Bool) types. Accepted values are
'y' and 'n' only, turning into true/false values, respectively.
- Single-character values. Can be used both as a substritute for
bool/tristate, or as a small-range integer:
- 'y'/'n'/'m' are represented as is, as characters 'y', 'n', or 'm';
- integers in a range [-128, 127] or [0, 255] (depending on signedness of
char in target architecture) are recognized and represented with
respective values of char type.
- Strings. String values are declared as fixed-length char arrays. String of
up to that length will be accepted and put in first N bytes of char array,
with the rest of bytes zeroed out. If config string value is longer than
space alloted, it will be truncated and warning message emitted. Char array
is always zero terminated. String literals in config have to be enclosed in
double quotes, just like C-style string literals.
- Integers. 8-, 16-, 32-, and 64-bit integers are supported, both signed and
unsigned variants. Libbpf enforces parsed config value to be in the
supported range of corresponding integer type. Integers values in config can
be:
- decimal integers, with optional + and - signs;
- hexadecimal integers, prefixed with 0x or 0X;
- octal integers, starting with 0.
Config file itself is searched in /boot/config-$(uname -r) location with
fallback to /proc/config.gz, unless config path is specified explicitly
through bpf_object_open_opts' kernel_config_path option. Both gzipped and
plain text formats are supported. Libbpf adds explicit dependency on zlib
because of this, but this shouldn't be a problem, given libelf already depends
on zlib.
All detected extern variables, are put into a separate .extern internal map.
It, similarly to .rodata map, is marked as read-only from BPF program side, as
well as is frozen on load. This allows BPF verifier to track extern values as
constants and perform enhanced branch prediction and dead code elimination.
This can be relied upon for doing kernel version/feature detection and using
potentially unsupported field relocations or BPF helpers in a CO-RE-based BPF
program, while still having a single version of BPF program running on old and
new kernels. Selftests are validating this explicitly for unexisting BPF
helper.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20191214014710.3449601-3-andriin@fb.com
2019-12-14 01:47:08 +00:00
|
|
|
enum libbpf_tristate {
|
|
|
|
TRI_NO = 0,
|
|
|
|
TRI_YES = 1,
|
|
|
|
TRI_MODULE = 2,
|
|
|
|
};
|
|
|
|
|
libbpf: Add BPF static linker APIs
Introduce BPF static linker APIs to libbpf. BPF static linker allows to
perform static linking of multiple BPF object files into a single combined
resulting object file, preserving all the BPF programs, maps, global
variables, etc.
Data sections (.bss, .data, .rodata, .maps, maps, etc) with the same name are
concatenated together. Similarly, code sections are also concatenated. All the
symbols and ELF relocations are also concatenated in their respective ELF
sections and are adjusted accordingly to the new object file layout.
Static variables and functions are handled correctly as well, adjusting BPF
instructions offsets to reflect new variable/function offset within the
combined ELF section. Such relocations are referencing STT_SECTION symbols and
that stays intact.
Data sections in different files can have different alignment requirements, so
that is taken care of as well, adjusting sizes and offsets as necessary to
satisfy both old and new alignment requirements.
DWARF data sections are stripped out, currently. As well as LLLVM_ADDRSIG
section, which is ignored by libbpf in bpf_object__open() anyways. So, in
a way, BPF static linker is an analogue to `llvm-strip -g`, which is a pretty
nice property, especially if resulting .o file is then used to generate BPF
skeleton.
Original string sections are ignored and instead we construct our own set of
unique strings using libbpf-internal `struct strset` API.
To reduce the size of the patch, all the .BTF and .BTF.ext processing was
moved into a separate patch.
The high-level API consists of just 4 functions:
- bpf_linker__new() creates an instance of BPF static linker. It accepts
output filename and (currently empty) options struct;
- bpf_linker__add_file() takes input filename and appends it to the already
processed ELF data; it can be called multiple times, one for each BPF
ELF object file that needs to be linked in;
- bpf_linker__finalize() needs to be called to dump final ELF contents into
the output file, specified when bpf_linker was created; after
bpf_linker__finalize() is called, no more bpf_linker__add_file() and
bpf_linker__finalize() calls are allowed, they will return error;
- regardless of whether bpf_linker__finalize() was called or not,
bpf_linker__free() will free up all the used resources.
Currently, BPF static linker doesn't resolve cross-object file references
(extern variables and/or functions). This will be added in the follow up patch
set.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20210318194036.3521577-7-andrii@kernel.org
2021-03-18 19:40:30 +00:00
|
|
|
struct bpf_linker_opts {
|
|
|
|
/* size of this struct, for forward/backward compatiblity */
|
|
|
|
size_t sz;
|
|
|
|
};
|
|
|
|
#define bpf_linker_opts__last_field sz
|
|
|
|
|
2021-05-07 05:41:14 +00:00
|
|
|
struct bpf_linker_file_opts {
|
|
|
|
/* size of this struct, for forward/backward compatiblity */
|
|
|
|
size_t sz;
|
|
|
|
};
|
|
|
|
#define bpf_linker_file_opts__last_field sz
|
|
|
|
|
libbpf: Add BPF static linker APIs
Introduce BPF static linker APIs to libbpf. BPF static linker allows to
perform static linking of multiple BPF object files into a single combined
resulting object file, preserving all the BPF programs, maps, global
variables, etc.
Data sections (.bss, .data, .rodata, .maps, maps, etc) with the same name are
concatenated together. Similarly, code sections are also concatenated. All the
symbols and ELF relocations are also concatenated in their respective ELF
sections and are adjusted accordingly to the new object file layout.
Static variables and functions are handled correctly as well, adjusting BPF
instructions offsets to reflect new variable/function offset within the
combined ELF section. Such relocations are referencing STT_SECTION symbols and
that stays intact.
Data sections in different files can have different alignment requirements, so
that is taken care of as well, adjusting sizes and offsets as necessary to
satisfy both old and new alignment requirements.
DWARF data sections are stripped out, currently. As well as LLLVM_ADDRSIG
section, which is ignored by libbpf in bpf_object__open() anyways. So, in
a way, BPF static linker is an analogue to `llvm-strip -g`, which is a pretty
nice property, especially if resulting .o file is then used to generate BPF
skeleton.
Original string sections are ignored and instead we construct our own set of
unique strings using libbpf-internal `struct strset` API.
To reduce the size of the patch, all the .BTF and .BTF.ext processing was
moved into a separate patch.
The high-level API consists of just 4 functions:
- bpf_linker__new() creates an instance of BPF static linker. It accepts
output filename and (currently empty) options struct;
- bpf_linker__add_file() takes input filename and appends it to the already
processed ELF data; it can be called multiple times, one for each BPF
ELF object file that needs to be linked in;
- bpf_linker__finalize() needs to be called to dump final ELF contents into
the output file, specified when bpf_linker was created; after
bpf_linker__finalize() is called, no more bpf_linker__add_file() and
bpf_linker__finalize() calls are allowed, they will return error;
- regardless of whether bpf_linker__finalize() was called or not,
bpf_linker__free() will free up all the used resources.
Currently, BPF static linker doesn't resolve cross-object file references
(extern variables and/or functions). This will be added in the follow up patch
set.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20210318194036.3521577-7-andrii@kernel.org
2021-03-18 19:40:30 +00:00
|
|
|
struct bpf_linker;
|
|
|
|
|
|
|
|
LIBBPF_API struct bpf_linker *bpf_linker__new(const char *filename, struct bpf_linker_opts *opts);
|
2021-05-07 05:41:14 +00:00
|
|
|
LIBBPF_API int bpf_linker__add_file(struct bpf_linker *linker,
|
|
|
|
const char *filename,
|
|
|
|
const struct bpf_linker_file_opts *opts);
|
libbpf: Add BPF static linker APIs
Introduce BPF static linker APIs to libbpf. BPF static linker allows to
perform static linking of multiple BPF object files into a single combined
resulting object file, preserving all the BPF programs, maps, global
variables, etc.
Data sections (.bss, .data, .rodata, .maps, maps, etc) with the same name are
concatenated together. Similarly, code sections are also concatenated. All the
symbols and ELF relocations are also concatenated in their respective ELF
sections and are adjusted accordingly to the new object file layout.
Static variables and functions are handled correctly as well, adjusting BPF
instructions offsets to reflect new variable/function offset within the
combined ELF section. Such relocations are referencing STT_SECTION symbols and
that stays intact.
Data sections in different files can have different alignment requirements, so
that is taken care of as well, adjusting sizes and offsets as necessary to
satisfy both old and new alignment requirements.
DWARF data sections are stripped out, currently. As well as LLLVM_ADDRSIG
section, which is ignored by libbpf in bpf_object__open() anyways. So, in
a way, BPF static linker is an analogue to `llvm-strip -g`, which is a pretty
nice property, especially if resulting .o file is then used to generate BPF
skeleton.
Original string sections are ignored and instead we construct our own set of
unique strings using libbpf-internal `struct strset` API.
To reduce the size of the patch, all the .BTF and .BTF.ext processing was
moved into a separate patch.
The high-level API consists of just 4 functions:
- bpf_linker__new() creates an instance of BPF static linker. It accepts
output filename and (currently empty) options struct;
- bpf_linker__add_file() takes input filename and appends it to the already
processed ELF data; it can be called multiple times, one for each BPF
ELF object file that needs to be linked in;
- bpf_linker__finalize() needs to be called to dump final ELF contents into
the output file, specified when bpf_linker was created; after
bpf_linker__finalize() is called, no more bpf_linker__add_file() and
bpf_linker__finalize() calls are allowed, they will return error;
- regardless of whether bpf_linker__finalize() was called or not,
bpf_linker__free() will free up all the used resources.
Currently, BPF static linker doesn't resolve cross-object file references
(extern variables and/or functions). This will be added in the follow up patch
set.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20210318194036.3521577-7-andrii@kernel.org
2021-03-18 19:40:30 +00:00
|
|
|
LIBBPF_API int bpf_linker__finalize(struct bpf_linker *linker);
|
|
|
|
LIBBPF_API void bpf_linker__free(struct bpf_linker *linker);
|
|
|
|
|
2018-11-21 17:29:44 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
} /* extern "C" */
|
|
|
|
#endif
|
|
|
|
|
2018-10-03 22:26:42 +00:00
|
|
|
#endif /* __LIBBPF_LIBBPF_H */
|