2022-01-24 23:16:20 +09:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
|
#ifndef __BPF_MISC_H__
|
|
|
|
|
#define __BPF_MISC_H__
|
|
|
|
|
|
2023-03-01 19:54:17 +02:00
|
|
|
/* This set of attributes controls behavior of the
|
|
|
|
|
* test_loader.c:test_loader__run_subtests().
|
|
|
|
|
*
|
|
|
|
|
* __msg Message expected to be found in the verifier log.
|
|
|
|
|
* Multiple __msg attributes could be specified.
|
|
|
|
|
*
|
|
|
|
|
* __success Expect program load success in privileged mode.
|
|
|
|
|
*
|
|
|
|
|
* __failure Expect program load failure in privileged mode.
|
|
|
|
|
*
|
|
|
|
|
* __log_level Log level to use for the program, numeric value expected.
|
|
|
|
|
*
|
|
|
|
|
* __flag Adds one flag use for the program, the following values are valid:
|
|
|
|
|
* - BPF_F_STRICT_ALIGNMENT;
|
|
|
|
|
* - BPF_F_TEST_RND_HI32;
|
|
|
|
|
* - BPF_F_TEST_STATE_FREQ;
|
|
|
|
|
* - BPF_F_SLEEPABLE;
|
|
|
|
|
* - BPF_F_XDP_HAS_FRAGS;
|
|
|
|
|
* - A numeric value.
|
|
|
|
|
* Multiple __flag attributes could be specified, the final flags
|
|
|
|
|
* value is derived by applying binary "or" to all specified values.
|
|
|
|
|
*/
|
selftests/bpf: add generic BPF program tester-loader
It's become a common pattern to have a collection of small BPF programs
in one BPF object file, each representing one test case. On user-space
side of such tests we maintain a table of program names and expected
failure or success, along with optional expected verifier log message.
This works, but each set of tests reimplement this mundane code over and
over again, which is a waste of time for anyone trying to add a new set
of tests. Furthermore, it's quite error prone as it's way too easy to miss
some entries in these manually maintained test tables (as evidences by
dynptr_fail tests, in which ringbuf_release_uninit_dynptr subtest was
accidentally missed; this is fixed in next patch).
So this patch implements generic test_loader, which accepts skeleton
name and handles the rest of details: opens and loads BPF object file,
making sure each program is tested in isolation. Optionally each test
case can specify expected BPF verifier log message. In case of failure,
tester makes sure to report verifier log, but it also reports verifier
log in verbose mode unconditionally.
Now, the interesting deviation from existing custom implementations is
the use of btf_decl_tag attribute to specify expected-to-fail vs
expected-to-succeed markers and, optionally, expected log message
directly next to BPF program source code, eliminating the need to
manually create and update table of tests.
We define few macros wrapping btf_decl_tag with a convention that all
values of btf_decl_tag start with "comment:" prefix, and then utilizing
a very simple "just_some_text_tag" or "some_key_name=<value>" pattern to
define things like expected success/failure, expected verifier message,
extra verifier log level (if necessary). This approach is demonstrated
by next patch in which two existing sets of failure tests are converted.
Tester supports both expected-to-fail and expected-to-succeed programs,
though this patch set didn't convert any existing expected-to-succeed
programs yet, as existing tests couple BPF program loading with their
further execution through attach or test_prog_run. One way to allow
testing scenarios like this would be ability to specify custom callback,
executed for each successfully loaded BPF program. This is left for
follow up patches, after some more analysis of existing test cases.
This test_loader is, hopefully, a start of a test_verifier-like runner,
but integrated into test_progs infrastructure. It will allow much better
"user experience" of defining low-level verification tests that can take
advantage of all the libbpf-provided nicety features on BPF side: global
variables, declarative maps, etc. All while having a choice of defining
it in C or as BPF assembly (through __attribute__((naked)) functions and
using embedded asm), depending on what makes most sense in each
particular case. This will be explored in follow up patches as well.
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20221207201648.2990661-1-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-12-07 12:16:47 -08:00
|
|
|
#define __msg(msg) __attribute__((btf_decl_tag("comment:test_expect_msg=" msg)))
|
|
|
|
|
#define __failure __attribute__((btf_decl_tag("comment:test_expect_failure")))
|
|
|
|
|
#define __success __attribute__((btf_decl_tag("comment:test_expect_success")))
|
|
|
|
|
#define __log_level(lvl) __attribute__((btf_decl_tag("comment:test_log_level="#lvl)))
|
2023-03-01 19:54:17 +02:00
|
|
|
#define __flag(flag) __attribute__((btf_decl_tag("comment:test_prog_flags="#flag)))
|
selftests/bpf: add generic BPF program tester-loader
It's become a common pattern to have a collection of small BPF programs
in one BPF object file, each representing one test case. On user-space
side of such tests we maintain a table of program names and expected
failure or success, along with optional expected verifier log message.
This works, but each set of tests reimplement this mundane code over and
over again, which is a waste of time for anyone trying to add a new set
of tests. Furthermore, it's quite error prone as it's way too easy to miss
some entries in these manually maintained test tables (as evidences by
dynptr_fail tests, in which ringbuf_release_uninit_dynptr subtest was
accidentally missed; this is fixed in next patch).
So this patch implements generic test_loader, which accepts skeleton
name and handles the rest of details: opens and loads BPF object file,
making sure each program is tested in isolation. Optionally each test
case can specify expected BPF verifier log message. In case of failure,
tester makes sure to report verifier log, but it also reports verifier
log in verbose mode unconditionally.
Now, the interesting deviation from existing custom implementations is
the use of btf_decl_tag attribute to specify expected-to-fail vs
expected-to-succeed markers and, optionally, expected log message
directly next to BPF program source code, eliminating the need to
manually create and update table of tests.
We define few macros wrapping btf_decl_tag with a convention that all
values of btf_decl_tag start with "comment:" prefix, and then utilizing
a very simple "just_some_text_tag" or "some_key_name=<value>" pattern to
define things like expected success/failure, expected verifier message,
extra verifier log level (if necessary). This approach is demonstrated
by next patch in which two existing sets of failure tests are converted.
Tester supports both expected-to-fail and expected-to-succeed programs,
though this patch set didn't convert any existing expected-to-succeed
programs yet, as existing tests couple BPF program loading with their
further execution through attach or test_prog_run. One way to allow
testing scenarios like this would be ability to specify custom callback,
executed for each successfully loaded BPF program. This is left for
follow up patches, after some more analysis of existing test cases.
This test_loader is, hopefully, a start of a test_verifier-like runner,
but integrated into test_progs infrastructure. It will allow much better
"user experience" of defining low-level verification tests that can take
advantage of all the libbpf-provided nicety features on BPF side: global
variables, declarative maps, etc. All while having a choice of defining
it in C or as BPF assembly (through __attribute__((naked)) functions and
using embedded asm), depending on what makes most sense in each
particular case. This will be explored in follow up patches as well.
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20221207201648.2990661-1-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-12-07 12:16:47 -08:00
|
|
|
|
2023-01-21 05:52:37 +05:30
|
|
|
/* Convenience macro for use with 'asm volatile' blocks */
|
|
|
|
|
#define __naked __attribute__((naked))
|
|
|
|
|
#define __clobber_all "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "memory"
|
|
|
|
|
#define __clobber_common "r0", "r1", "r2", "r3", "r4", "r5", "memory"
|
|
|
|
|
#define __imm(name) [name]"i"(name)
|
|
|
|
|
#define __imm_addr(name) [name]"i"(&name)
|
2023-03-08 10:41:19 -08:00
|
|
|
#define __imm_ptr(name) [name]"p"(&name)
|
2023-01-21 05:52:37 +05:30
|
|
|
|
2022-01-24 23:16:20 +09:00
|
|
|
#if defined(__TARGET_ARCH_x86)
|
|
|
|
|
#define SYSCALL_WRAPPER 1
|
|
|
|
|
#define SYS_PREFIX "__x64_"
|
|
|
|
|
#elif defined(__TARGET_ARCH_s390)
|
|
|
|
|
#define SYSCALL_WRAPPER 1
|
|
|
|
|
#define SYS_PREFIX "__s390x_"
|
|
|
|
|
#elif defined(__TARGET_ARCH_arm64)
|
|
|
|
|
#define SYSCALL_WRAPPER 1
|
|
|
|
|
#define SYS_PREFIX "__arm64_"
|
|
|
|
|
#else
|
|
|
|
|
#define SYSCALL_WRAPPER 0
|
2022-02-04 17:05:19 +05:30
|
|
|
#define SYS_PREFIX "__se_"
|
2022-01-24 23:16:20 +09:00
|
|
|
#endif
|
|
|
|
|
|
2023-01-20 12:09:00 -08:00
|
|
|
/* How many arguments are passed to function in register */
|
|
|
|
|
#if defined(__TARGET_ARCH_x86) || defined(__x86_64__)
|
|
|
|
|
#define FUNC_REG_ARG_CNT 6
|
|
|
|
|
#elif defined(__i386__)
|
|
|
|
|
#define FUNC_REG_ARG_CNT 3
|
|
|
|
|
#elif defined(__TARGET_ARCH_s390) || defined(__s390x__)
|
|
|
|
|
#define FUNC_REG_ARG_CNT 5
|
|
|
|
|
#elif defined(__TARGET_ARCH_arm) || defined(__arm__)
|
|
|
|
|
#define FUNC_REG_ARG_CNT 4
|
|
|
|
|
#elif defined(__TARGET_ARCH_arm64) || defined(__aarch64__)
|
|
|
|
|
#define FUNC_REG_ARG_CNT 8
|
|
|
|
|
#elif defined(__TARGET_ARCH_mips) || defined(__mips__)
|
|
|
|
|
#define FUNC_REG_ARG_CNT 8
|
|
|
|
|
#elif defined(__TARGET_ARCH_powerpc) || defined(__powerpc__) || defined(__powerpc64__)
|
|
|
|
|
#define FUNC_REG_ARG_CNT 8
|
|
|
|
|
#elif defined(__TARGET_ARCH_sparc) || defined(__sparc__)
|
|
|
|
|
#define FUNC_REG_ARG_CNT 6
|
|
|
|
|
#elif defined(__TARGET_ARCH_riscv) || defined(__riscv__)
|
|
|
|
|
#define FUNC_REG_ARG_CNT 8
|
|
|
|
|
#else
|
|
|
|
|
/* default to 5 for others */
|
|
|
|
|
#define FUNC_REG_ARG_CNT 5
|
|
|
|
|
#endif
|
|
|
|
|
|
2023-03-08 21:40:13 -08:00
|
|
|
/* make it look to compiler like value is read and written */
|
|
|
|
|
#define __sink(expr) asm volatile("" : "+g"(expr))
|
|
|
|
|
|
selftests/bpf: add bpf_for_each(), bpf_for(), and bpf_repeat() macros
Add bpf_for_each(), bpf_for(), and bpf_repeat() macros that make writing
open-coded iterator-based loops much more convenient and natural. These
macros utilize cleanup attribute to ensure proper destruction of the
iterator and thanks to that manage to provide the ergonomics that is
very close to C language's for() construct. Typical loop would look like:
int i;
int arr[N];
bpf_for(i, 0, N) {
/* verifier will know that i >= 0 && i < N, so could be used to
* directly access array elements with no extra checks
*/
arr[i] = i;
}
bpf_repeat() is very similar, but it doesn't expose iteration number and
is meant as a simple "repeat action N times" loop:
bpf_repeat(N) { /* whatever, N times */ }
Note that `break` and `continue` statements inside the {} block work as
expected.
bpf_for_each() is a generalization over any kind of BPF open-coded
iterator allowing to use for-each-like approach instead of calling
low-level bpf_iter_<type>_{new,next,destroy}() APIs explicitly. E.g.:
struct cgroup *cg;
bpf_for_each(cgroup, cg, some, input, args) {
/* do something with each cg */
}
would call (not-yet-implemented) bpf_iter_cgroup_{new,next,destroy}()
functions to form a loop over cgroups, where `some, input, args` are
passed verbatim into constructor as
bpf_iter_cgroup_new(&it, some, input, args).
As a first demonstration, add pyperf variant based on the bpf_for() loop.
Also clean up a few tests that either included bpf_misc.h header
unnecessarily from the user-space, which is unsupported, or included it
before any common types are defined (and thus leading to unnecessary
compilation warnings, potentially).
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20230308184121.1165081-6-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-03-08 10:41:18 -08:00
|
|
|
struct bpf_iter_num;
|
|
|
|
|
|
|
|
|
|
extern int bpf_iter_num_new(struct bpf_iter_num *it, int start, int end) __ksym;
|
|
|
|
|
extern int *bpf_iter_num_next(struct bpf_iter_num *it) __ksym;
|
|
|
|
|
extern void bpf_iter_num_destroy(struct bpf_iter_num *it) __ksym;
|
|
|
|
|
|
|
|
|
|
#ifndef bpf_for_each
|
|
|
|
|
/* bpf_for_each(iter_type, cur_elem, args...) provides generic construct for
|
|
|
|
|
* using BPF open-coded iterators without having to write mundane explicit
|
|
|
|
|
* low-level loop logic. Instead, it provides for()-like generic construct
|
|
|
|
|
* that can be used pretty naturally. E.g., for some hypothetical cgroup
|
|
|
|
|
* iterator, you'd write:
|
|
|
|
|
*
|
|
|
|
|
* struct cgroup *cg, *parent_cg = <...>;
|
|
|
|
|
*
|
|
|
|
|
* bpf_for_each(cgroup, cg, parent_cg, CG_ITER_CHILDREN) {
|
|
|
|
|
* bpf_printk("Child cgroup id = %d", cg->cgroup_id);
|
|
|
|
|
* if (cg->cgroup_id == 123)
|
|
|
|
|
* break;
|
|
|
|
|
* }
|
|
|
|
|
*
|
|
|
|
|
* I.e., it looks almost like high-level for each loop in other languages,
|
|
|
|
|
* supports continue/break, and is verifiable by BPF verifier.
|
|
|
|
|
*
|
|
|
|
|
* For iterating integers, the difference betwen bpf_for_each(num, i, N, M)
|
|
|
|
|
* and bpf_for(i, N, M) is in that bpf_for() provides additional proof to
|
|
|
|
|
* verifier that i is in [N, M) range, and in bpf_for_each() case i is `int
|
|
|
|
|
* *`, not just `int`. So for integers bpf_for() is more convenient.
|
|
|
|
|
*
|
|
|
|
|
* Note: this macro relies on C99 feature of allowing to declare variables
|
|
|
|
|
* inside for() loop, bound to for() loop lifetime. It also utilizes GCC
|
|
|
|
|
* extension: __attribute__((cleanup(<func>))), supported by both GCC and
|
|
|
|
|
* Clang.
|
|
|
|
|
*/
|
|
|
|
|
#define bpf_for_each(type, cur, args...) for ( \
|
|
|
|
|
/* initialize and define destructor */ \
|
|
|
|
|
struct bpf_iter_##type ___it __attribute__((aligned(8), /* enforce, just in case */, \
|
|
|
|
|
cleanup(bpf_iter_##type##_destroy))), \
|
|
|
|
|
/* ___p pointer is just to call bpf_iter_##type##_new() *once* to init ___it */ \
|
2023-03-08 21:40:12 -08:00
|
|
|
*___p __attribute__((unused)) = ( \
|
|
|
|
|
bpf_iter_##type##_new(&___it, ##args), \
|
selftests/bpf: add bpf_for_each(), bpf_for(), and bpf_repeat() macros
Add bpf_for_each(), bpf_for(), and bpf_repeat() macros that make writing
open-coded iterator-based loops much more convenient and natural. These
macros utilize cleanup attribute to ensure proper destruction of the
iterator and thanks to that manage to provide the ergonomics that is
very close to C language's for() construct. Typical loop would look like:
int i;
int arr[N];
bpf_for(i, 0, N) {
/* verifier will know that i >= 0 && i < N, so could be used to
* directly access array elements with no extra checks
*/
arr[i] = i;
}
bpf_repeat() is very similar, but it doesn't expose iteration number and
is meant as a simple "repeat action N times" loop:
bpf_repeat(N) { /* whatever, N times */ }
Note that `break` and `continue` statements inside the {} block work as
expected.
bpf_for_each() is a generalization over any kind of BPF open-coded
iterator allowing to use for-each-like approach instead of calling
low-level bpf_iter_<type>_{new,next,destroy}() APIs explicitly. E.g.:
struct cgroup *cg;
bpf_for_each(cgroup, cg, some, input, args) {
/* do something with each cg */
}
would call (not-yet-implemented) bpf_iter_cgroup_{new,next,destroy}()
functions to form a loop over cgroups, where `some, input, args` are
passed verbatim into constructor as
bpf_iter_cgroup_new(&it, some, input, args).
As a first demonstration, add pyperf variant based on the bpf_for() loop.
Also clean up a few tests that either included bpf_misc.h header
unnecessarily from the user-space, which is unsupported, or included it
before any common types are defined (and thus leading to unnecessary
compilation warnings, potentially).
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20230308184121.1165081-6-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-03-08 10:41:18 -08:00
|
|
|
/* this is a workaround for Clang bug: it currently doesn't emit BTF */ \
|
|
|
|
|
/* for bpf_iter_##type##_destroy() when used from cleanup() attribute */ \
|
|
|
|
|
(void)bpf_iter_##type##_destroy, (void *)0); \
|
|
|
|
|
/* iteration and termination check */ \
|
|
|
|
|
(((cur) = bpf_iter_##type##_next(&___it))); \
|
|
|
|
|
)
|
|
|
|
|
#endif /* bpf_for_each */
|
|
|
|
|
|
|
|
|
|
#ifndef bpf_for
|
|
|
|
|
/* bpf_for(i, start, end) implements a for()-like looping construct that sets
|
|
|
|
|
* provided integer variable *i* to values starting from *start* through,
|
|
|
|
|
* but not including, *end*. It also proves to BPF verifier that *i* belongs
|
|
|
|
|
* to range [start, end), so this can be used for accessing arrays without
|
|
|
|
|
* extra checks.
|
|
|
|
|
*
|
|
|
|
|
* Note: *start* and *end* are assumed to be expressions with no side effects
|
|
|
|
|
* and whose values do not change throughout bpf_for() loop execution. They do
|
|
|
|
|
* not have to be statically known or constant, though.
|
|
|
|
|
*
|
|
|
|
|
* Note: similarly to bpf_for_each(), it relies on C99 feature of declaring for()
|
|
|
|
|
* loop bound variables and cleanup attribute, supported by GCC and Clang.
|
|
|
|
|
*/
|
|
|
|
|
#define bpf_for(i, start, end) for ( \
|
|
|
|
|
/* initialize and define destructor */ \
|
|
|
|
|
struct bpf_iter_num ___it __attribute__((aligned(8), /* enforce, just in case */ \
|
|
|
|
|
cleanup(bpf_iter_num_destroy))), \
|
|
|
|
|
/* ___p pointer is necessary to call bpf_iter_num_new() *once* to init ___it */ \
|
2023-03-08 21:40:12 -08:00
|
|
|
*___p __attribute__((unused)) = ( \
|
|
|
|
|
bpf_iter_num_new(&___it, (start), (end)), \
|
selftests/bpf: add bpf_for_each(), bpf_for(), and bpf_repeat() macros
Add bpf_for_each(), bpf_for(), and bpf_repeat() macros that make writing
open-coded iterator-based loops much more convenient and natural. These
macros utilize cleanup attribute to ensure proper destruction of the
iterator and thanks to that manage to provide the ergonomics that is
very close to C language's for() construct. Typical loop would look like:
int i;
int arr[N];
bpf_for(i, 0, N) {
/* verifier will know that i >= 0 && i < N, so could be used to
* directly access array elements with no extra checks
*/
arr[i] = i;
}
bpf_repeat() is very similar, but it doesn't expose iteration number and
is meant as a simple "repeat action N times" loop:
bpf_repeat(N) { /* whatever, N times */ }
Note that `break` and `continue` statements inside the {} block work as
expected.
bpf_for_each() is a generalization over any kind of BPF open-coded
iterator allowing to use for-each-like approach instead of calling
low-level bpf_iter_<type>_{new,next,destroy}() APIs explicitly. E.g.:
struct cgroup *cg;
bpf_for_each(cgroup, cg, some, input, args) {
/* do something with each cg */
}
would call (not-yet-implemented) bpf_iter_cgroup_{new,next,destroy}()
functions to form a loop over cgroups, where `some, input, args` are
passed verbatim into constructor as
bpf_iter_cgroup_new(&it, some, input, args).
As a first demonstration, add pyperf variant based on the bpf_for() loop.
Also clean up a few tests that either included bpf_misc.h header
unnecessarily from the user-space, which is unsupported, or included it
before any common types are defined (and thus leading to unnecessary
compilation warnings, potentially).
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20230308184121.1165081-6-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-03-08 10:41:18 -08:00
|
|
|
/* this is a workaround for Clang bug: it currently doesn't emit BTF */ \
|
|
|
|
|
/* for bpf_iter_num_destroy() when used from cleanup() attribute */ \
|
|
|
|
|
(void)bpf_iter_num_destroy, (void *)0); \
|
|
|
|
|
({ \
|
|
|
|
|
/* iteration step */ \
|
|
|
|
|
int *___t = bpf_iter_num_next(&___it); \
|
|
|
|
|
/* termination and bounds check */ \
|
|
|
|
|
(___t && ((i) = *___t, (i) >= (start) && (i) < (end))); \
|
|
|
|
|
}); \
|
|
|
|
|
)
|
|
|
|
|
#endif /* bpf_for */
|
|
|
|
|
|
|
|
|
|
#ifndef bpf_repeat
|
|
|
|
|
/* bpf_repeat(N) performs N iterations without exposing iteration number
|
|
|
|
|
*
|
|
|
|
|
* Note: similarly to bpf_for_each(), it relies on C99 feature of declaring for()
|
|
|
|
|
* loop bound variables and cleanup attribute, supported by GCC and Clang.
|
|
|
|
|
*/
|
|
|
|
|
#define bpf_repeat(N) for ( \
|
|
|
|
|
/* initialize and define destructor */ \
|
|
|
|
|
struct bpf_iter_num ___it __attribute__((aligned(8), /* enforce, just in case */ \
|
|
|
|
|
cleanup(bpf_iter_num_destroy))), \
|
|
|
|
|
/* ___p pointer is necessary to call bpf_iter_num_new() *once* to init ___it */ \
|
2023-03-08 21:40:12 -08:00
|
|
|
*___p __attribute__((unused)) = ( \
|
|
|
|
|
bpf_iter_num_new(&___it, 0, (N)), \
|
selftests/bpf: add bpf_for_each(), bpf_for(), and bpf_repeat() macros
Add bpf_for_each(), bpf_for(), and bpf_repeat() macros that make writing
open-coded iterator-based loops much more convenient and natural. These
macros utilize cleanup attribute to ensure proper destruction of the
iterator and thanks to that manage to provide the ergonomics that is
very close to C language's for() construct. Typical loop would look like:
int i;
int arr[N];
bpf_for(i, 0, N) {
/* verifier will know that i >= 0 && i < N, so could be used to
* directly access array elements with no extra checks
*/
arr[i] = i;
}
bpf_repeat() is very similar, but it doesn't expose iteration number and
is meant as a simple "repeat action N times" loop:
bpf_repeat(N) { /* whatever, N times */ }
Note that `break` and `continue` statements inside the {} block work as
expected.
bpf_for_each() is a generalization over any kind of BPF open-coded
iterator allowing to use for-each-like approach instead of calling
low-level bpf_iter_<type>_{new,next,destroy}() APIs explicitly. E.g.:
struct cgroup *cg;
bpf_for_each(cgroup, cg, some, input, args) {
/* do something with each cg */
}
would call (not-yet-implemented) bpf_iter_cgroup_{new,next,destroy}()
functions to form a loop over cgroups, where `some, input, args` are
passed verbatim into constructor as
bpf_iter_cgroup_new(&it, some, input, args).
As a first demonstration, add pyperf variant based on the bpf_for() loop.
Also clean up a few tests that either included bpf_misc.h header
unnecessarily from the user-space, which is unsupported, or included it
before any common types are defined (and thus leading to unnecessary
compilation warnings, potentially).
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20230308184121.1165081-6-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-03-08 10:41:18 -08:00
|
|
|
/* this is a workaround for Clang bug: it currently doesn't emit BTF */ \
|
|
|
|
|
/* for bpf_iter_num_destroy() when used from cleanup() attribute */ \
|
|
|
|
|
(void)bpf_iter_num_destroy, (void *)0); \
|
|
|
|
|
bpf_iter_num_next(&___it); \
|
|
|
|
|
/* nothing here */ \
|
|
|
|
|
)
|
|
|
|
|
#endif /* bpf_repeat */
|
2023-01-20 12:09:00 -08:00
|
|
|
|
2022-01-24 23:16:20 +09:00
|
|
|
#endif
|