2021-05-25 03:59:31 +00:00
|
|
|
/* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Libbpf legacy APIs (either discouraged or deprecated, as mentioned in [0])
|
|
|
|
*
|
|
|
|
* [0] https://docs.google.com/document/d/1UyjTZuPFWiPFyKk1tV5an11_iaRuec6U-ZESZ54nNTY
|
|
|
|
*
|
|
|
|
* Copyright (C) 2021 Facebook
|
|
|
|
*/
|
|
|
|
#ifndef __LIBBPF_LEGACY_BPF_H
|
|
|
|
#define __LIBBPF_LEGACY_BPF_H
|
|
|
|
|
|
|
|
#include <linux/bpf.h>
|
|
|
|
#include <stdbool.h>
|
|
|
|
#include <stddef.h>
|
|
|
|
#include <stdint.h>
|
|
|
|
#include "libbpf_common.h"
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2022-06-27 21:15:26 +00:00
|
|
|
/* As of libbpf 1.0 libbpf_set_strict_mode() and enum libbpf_struct_mode have
|
|
|
|
* no effect. But they are left in libbpf_legacy.h so that applications that
|
|
|
|
* prepared for libbpf 1.0 before final release by using
|
|
|
|
* libbpf_set_strict_mode() still work with libbpf 1.0+ without any changes.
|
|
|
|
*/
|
2021-05-25 03:59:31 +00:00
|
|
|
enum libbpf_strict_mode {
|
|
|
|
/* Turn on all supported strict features of libbpf to simulate libbpf
|
|
|
|
* v1.0 behavior.
|
|
|
|
* This will be the default behavior in libbpf v1.0.
|
|
|
|
*/
|
|
|
|
LIBBPF_STRICT_ALL = 0xffffffff,
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Disable any libbpf 1.0 behaviors. This is the default before libbpf
|
|
|
|
* v1.0. It won't be supported anymore in v1.0, please update your
|
|
|
|
* code so that it handles LIBBPF_STRICT_ALL mode before libbpf v1.0.
|
|
|
|
*/
|
|
|
|
LIBBPF_STRICT_NONE = 0x00,
|
2021-05-25 03:59:33 +00:00
|
|
|
/*
|
|
|
|
* Return NULL pointers on error, not ERR_PTR(err).
|
|
|
|
* Additionally, libbpf also always sets errno to corresponding Exx
|
|
|
|
* (positive) error code.
|
|
|
|
*/
|
|
|
|
LIBBPF_STRICT_CLEAN_PTRS = 0x01,
|
|
|
|
/*
|
|
|
|
* Return actual error codes from low-level APIs directly, not just -1.
|
|
|
|
* Additionally, libbpf also always sets errno to corresponding Exx
|
|
|
|
* (positive) error code.
|
|
|
|
*/
|
|
|
|
LIBBPF_STRICT_DIRECT_ERRS = 0x02,
|
libbpf: Add opt-in strict BPF program section name handling logic
Implement strict ELF section name handling for BPF programs. It utilizes
`libbpf_set_strict_mode()` framework and adds new flag: LIBBPF_STRICT_SEC_NAME.
If this flag is set, libbpf will enforce exact section name matching for
a lot of program types that previously allowed just partial prefix
match. E.g., if previously SEC("xdp_whatever_i_want") was allowed, now
in strict mode only SEC("xdp") will be accepted, which makes SEC("")
definitions cleaner and more structured. SEC() now won't be used as yet
another way to uniquely encode BPF program identifier (for that
C function name is better and is guaranteed to be unique within
bpf_object). Now SEC() is strictly BPF program type and, depending on
program type, extra load/attach parameter specification.
Libbpf completely supports multiple BPF programs in the same ELF
section, so multiple BPF programs of the same type/specification easily
co-exist together within the same bpf_object scope.
Additionally, a new (for now internal) convention is introduced: section
name that can be a stand-alone exact BPF program type specificator, but
also could have extra parameters after '/' delimiter. An example of such
section is "struct_ops", which can be specified by itself, but also
allows to specify the intended operation to be attached to, e.g.,
"struct_ops/dctcp_init". Note, that "struct_ops_some_op" is not allowed.
Such section definition is specified as "struct_ops+".
This change is part of libbpf 1.0 effort ([0], [1]).
[0] Closes: https://github.com/libbpf/libbpf/issues/271
[1] https://github.com/libbpf/libbpf/wiki/Libbpf:-the-road-to-v1.0#stricter-and-more-uniform-bpf-program-section-name-sec-handling
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Dave Marchevsky <davemarchevsky@fb.com>
Link: https://lore.kernel.org/bpf/20210928161946.2512801-10-andrii@kernel.org
2021-09-28 16:19:45 +00:00
|
|
|
/*
|
|
|
|
* Enforce strict BPF program section (SEC()) names.
|
|
|
|
* E.g., while prefiously SEC("xdp_whatever") or SEC("perf_event_blah") were
|
|
|
|
* allowed, with LIBBPF_STRICT_SEC_PREFIX this will become
|
|
|
|
* unrecognized by libbpf and would have to be just SEC("xdp") and
|
|
|
|
* SEC("xdp") and SEC("perf_event").
|
2021-10-21 21:48:12 +00:00
|
|
|
*
|
|
|
|
* Note, in this mode the program pin path will be based on the
|
|
|
|
* function name instead of section name.
|
2022-03-16 23:37:24 +00:00
|
|
|
*
|
|
|
|
* Additionally, routines in the .text section are always considered
|
|
|
|
* sub-programs. Legacy behavior allows for a single routine in .text
|
|
|
|
* to be a program.
|
libbpf: Add opt-in strict BPF program section name handling logic
Implement strict ELF section name handling for BPF programs. It utilizes
`libbpf_set_strict_mode()` framework and adds new flag: LIBBPF_STRICT_SEC_NAME.
If this flag is set, libbpf will enforce exact section name matching for
a lot of program types that previously allowed just partial prefix
match. E.g., if previously SEC("xdp_whatever_i_want") was allowed, now
in strict mode only SEC("xdp") will be accepted, which makes SEC("")
definitions cleaner and more structured. SEC() now won't be used as yet
another way to uniquely encode BPF program identifier (for that
C function name is better and is guaranteed to be unique within
bpf_object). Now SEC() is strictly BPF program type and, depending on
program type, extra load/attach parameter specification.
Libbpf completely supports multiple BPF programs in the same ELF
section, so multiple BPF programs of the same type/specification easily
co-exist together within the same bpf_object scope.
Additionally, a new (for now internal) convention is introduced: section
name that can be a stand-alone exact BPF program type specificator, but
also could have extra parameters after '/' delimiter. An example of such
section is "struct_ops", which can be specified by itself, but also
allows to specify the intended operation to be attached to, e.g.,
"struct_ops/dctcp_init". Note, that "struct_ops_some_op" is not allowed.
Such section definition is specified as "struct_ops+".
This change is part of libbpf 1.0 effort ([0], [1]).
[0] Closes: https://github.com/libbpf/libbpf/issues/271
[1] https://github.com/libbpf/libbpf/wiki/Libbpf:-the-road-to-v1.0#stricter-and-more-uniform-bpf-program-section-name-sec-handling
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Dave Marchevsky <davemarchevsky@fb.com>
Link: https://lore.kernel.org/bpf/20210928161946.2512801-10-andrii@kernel.org
2021-09-28 16:19:45 +00:00
|
|
|
*/
|
|
|
|
LIBBPF_STRICT_SEC_NAME = 0x04,
|
2021-10-26 22:35:28 +00:00
|
|
|
/*
|
|
|
|
* Disable the global 'bpf_objects_list'. Maintaining this list adds
|
|
|
|
* a race condition to bpf_object__open() and bpf_object__close().
|
|
|
|
* Clients can maintain it on their own if it is valuable for them.
|
|
|
|
*/
|
|
|
|
LIBBPF_STRICT_NO_OBJECT_LIST = 0x08,
|
libbpf: Auto-bump RLIMIT_MEMLOCK if kernel needs it for BPF
The need to increase RLIMIT_MEMLOCK to do anything useful with BPF is
one of the first extremely frustrating gotchas that all new BPF users go
through and in some cases have to learn it a very hard way.
Luckily, starting with upstream Linux kernel version 5.11, BPF subsystem
dropped the dependency on memlock and uses memcg-based memory accounting
instead. Unfortunately, detecting memcg-based BPF memory accounting is
far from trivial (as can be evidenced by this patch), so in practice
most BPF applications still do unconditional RLIMIT_MEMLOCK increase.
As we move towards libbpf 1.0, it would be good to allow users to forget
about RLIMIT_MEMLOCK vs memcg and let libbpf do the sensible adjustment
automatically. This patch paves the way forward in this matter. Libbpf
will do feature detection of memcg-based accounting, and if detected,
will do nothing. But if the kernel is too old, just like BCC, libbpf
will automatically increase RLIMIT_MEMLOCK on behalf of user
application ([0]).
As this is technically a breaking change, during the transition period
applications have to opt into libbpf 1.0 mode by setting
LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK bit when calling
libbpf_set_strict_mode().
Libbpf allows to control the exact amount of set RLIMIT_MEMLOCK limit
with libbpf_set_memlock_rlim_max() API. Passing 0 will make libbpf do
nothing with RLIMIT_MEMLOCK. libbpf_set_memlock_rlim_max() has to be
called before the first bpf_prog_load(), bpf_btf_load(), or
bpf_object__load() call, otherwise it has no effect and will return
-EBUSY.
[0] Closes: https://github.com/libbpf/libbpf/issues/369
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20211214195904.1785155-2-andrii@kernel.org
2021-12-14 19:59:03 +00:00
|
|
|
/*
|
|
|
|
* Automatically bump RLIMIT_MEMLOCK using setrlimit() before the
|
|
|
|
* first BPF program or map creation operation. This is done only if
|
|
|
|
* kernel is too old to support memcg-based memory accounting for BPF
|
|
|
|
* subsystem. By default, RLIMIT_MEMLOCK limit is set to RLIM_INFINITY,
|
2022-06-27 21:15:27 +00:00
|
|
|
* but it can be overriden with libbpf_set_memlock_rlim() API.
|
|
|
|
* Note that libbpf_set_memlock_rlim() needs to be called before
|
libbpf: Auto-bump RLIMIT_MEMLOCK if kernel needs it for BPF
The need to increase RLIMIT_MEMLOCK to do anything useful with BPF is
one of the first extremely frustrating gotchas that all new BPF users go
through and in some cases have to learn it a very hard way.
Luckily, starting with upstream Linux kernel version 5.11, BPF subsystem
dropped the dependency on memlock and uses memcg-based memory accounting
instead. Unfortunately, detecting memcg-based BPF memory accounting is
far from trivial (as can be evidenced by this patch), so in practice
most BPF applications still do unconditional RLIMIT_MEMLOCK increase.
As we move towards libbpf 1.0, it would be good to allow users to forget
about RLIMIT_MEMLOCK vs memcg and let libbpf do the sensible adjustment
automatically. This patch paves the way forward in this matter. Libbpf
will do feature detection of memcg-based accounting, and if detected,
will do nothing. But if the kernel is too old, just like BCC, libbpf
will automatically increase RLIMIT_MEMLOCK on behalf of user
application ([0]).
As this is technically a breaking change, during the transition period
applications have to opt into libbpf 1.0 mode by setting
LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK bit when calling
libbpf_set_strict_mode().
Libbpf allows to control the exact amount of set RLIMIT_MEMLOCK limit
with libbpf_set_memlock_rlim_max() API. Passing 0 will make libbpf do
nothing with RLIMIT_MEMLOCK. libbpf_set_memlock_rlim_max() has to be
called before the first bpf_prog_load(), bpf_btf_load(), or
bpf_object__load() call, otherwise it has no effect and will return
-EBUSY.
[0] Closes: https://github.com/libbpf/libbpf/issues/369
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20211214195904.1785155-2-andrii@kernel.org
2021-12-14 19:59:03 +00:00
|
|
|
* the very first bpf_prog_load(), bpf_map_create() or bpf_object__load()
|
|
|
|
* operation.
|
|
|
|
*/
|
|
|
|
LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK = 0x10,
|
2022-01-20 06:05:28 +00:00
|
|
|
/*
|
|
|
|
* Error out on any SEC("maps") map definition, which are deprecated
|
|
|
|
* in favor of BTF-defined map definitions in SEC(".maps").
|
|
|
|
*/
|
|
|
|
LIBBPF_STRICT_MAP_DEFINITIONS = 0x20,
|
libbpf: Add opt-in strict BPF program section name handling logic
Implement strict ELF section name handling for BPF programs. It utilizes
`libbpf_set_strict_mode()` framework and adds new flag: LIBBPF_STRICT_SEC_NAME.
If this flag is set, libbpf will enforce exact section name matching for
a lot of program types that previously allowed just partial prefix
match. E.g., if previously SEC("xdp_whatever_i_want") was allowed, now
in strict mode only SEC("xdp") will be accepted, which makes SEC("")
definitions cleaner and more structured. SEC() now won't be used as yet
another way to uniquely encode BPF program identifier (for that
C function name is better and is guaranteed to be unique within
bpf_object). Now SEC() is strictly BPF program type and, depending on
program type, extra load/attach parameter specification.
Libbpf completely supports multiple BPF programs in the same ELF
section, so multiple BPF programs of the same type/specification easily
co-exist together within the same bpf_object scope.
Additionally, a new (for now internal) convention is introduced: section
name that can be a stand-alone exact BPF program type specificator, but
also could have extra parameters after '/' delimiter. An example of such
section is "struct_ops", which can be specified by itself, but also
allows to specify the intended operation to be attached to, e.g.,
"struct_ops/dctcp_init". Note, that "struct_ops_some_op" is not allowed.
Such section definition is specified as "struct_ops+".
This change is part of libbpf 1.0 effort ([0], [1]).
[0] Closes: https://github.com/libbpf/libbpf/issues/271
[1] https://github.com/libbpf/libbpf/wiki/Libbpf:-the-road-to-v1.0#stricter-and-more-uniform-bpf-program-section-name-sec-handling
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Dave Marchevsky <davemarchevsky@fb.com>
Link: https://lore.kernel.org/bpf/20210928161946.2512801-10-andrii@kernel.org
2021-09-28 16:19:45 +00:00
|
|
|
|
2021-05-25 03:59:31 +00:00
|
|
|
__LIBBPF_STRICT_LAST,
|
|
|
|
};
|
|
|
|
|
|
|
|
LIBBPF_API int libbpf_set_strict_mode(enum libbpf_strict_mode mode);
|
|
|
|
|
2022-06-27 21:15:26 +00:00
|
|
|
/**
|
|
|
|
* @brief **libbpf_get_error()** extracts the error code from the passed
|
|
|
|
* pointer
|
|
|
|
* @param ptr pointer returned from libbpf API function
|
|
|
|
* @return error code; or 0 if no error occured
|
|
|
|
*
|
|
|
|
* Note, as of libbpf 1.0 this function is not necessary and not recommended
|
|
|
|
* to be used. Libbpf doesn't return error code embedded into the pointer
|
|
|
|
* itself. Instead, NULL is returned on error and error code is passed through
|
|
|
|
* thread-local errno variable. **libbpf_get_error()** is just returning -errno
|
|
|
|
* value if it receives NULL, which is correct only if errno hasn't been
|
|
|
|
* modified between libbpf API call and corresponding **libbpf_get_error()**
|
|
|
|
* call. Prefer to check return for NULL and use errno directly.
|
|
|
|
*
|
|
|
|
* This API is left in libbpf 1.0 to allow applications that were 1.0-ready
|
|
|
|
* before final libbpf 1.0 without needing to change them.
|
|
|
|
*/
|
|
|
|
LIBBPF_API long libbpf_get_error(const void *ptr);
|
|
|
|
|
2021-11-03 22:08:34 +00:00
|
|
|
#define DECLARE_LIBBPF_OPTS LIBBPF_OPTS
|
2021-05-25 03:59:31 +00:00
|
|
|
|
2022-01-24 19:42:48 +00:00
|
|
|
/* "Discouraged" APIs which don't follow consistent libbpf naming patterns.
|
|
|
|
* They are normally a trivial aliases or wrappers for proper APIs and are
|
|
|
|
* left to minimize unnecessary disruption for users of libbpf. But they
|
|
|
|
* shouldn't be used going forward.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct bpf_program;
|
|
|
|
struct bpf_map;
|
|
|
|
struct btf;
|
|
|
|
struct btf_ext;
|
|
|
|
|
2022-08-16 00:19:28 +00:00
|
|
|
LIBBPF_API struct btf *libbpf_find_kernel_btf(void);
|
|
|
|
|
2022-01-24 19:42:48 +00:00
|
|
|
LIBBPF_API enum bpf_prog_type bpf_program__get_type(const struct bpf_program *prog);
|
|
|
|
LIBBPF_API enum bpf_attach_type bpf_program__get_expected_attach_type(const struct bpf_program *prog);
|
|
|
|
LIBBPF_API const char *bpf_map__get_pin_path(const struct bpf_map *map);
|
|
|
|
LIBBPF_API const void *btf__get_raw_data(const struct btf *btf, __u32 *size);
|
|
|
|
LIBBPF_API const void *btf_ext__get_raw_data(const struct btf_ext *btf_ext, __u32 *size);
|
|
|
|
|
2021-05-25 03:59:31 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
} /* extern "C" */
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#endif /* __LIBBPF_LEGACY_BPF_H */
|