.../selftests/bpf/prog_tests/libbpf_probes.c | 33 +++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-)
At the moment libbpf_probe_prog_types test iterates over all available
BPF_PROG_TYPE regardless of kernel configuration which can exclude some
of those. Unfortunately there is no direct way to tell which types are
available, but we can look at struct bpf_ctx_onvert to tell which ones
are available.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
---
.../selftests/bpf/prog_tests/libbpf_probes.c | 33 +++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c b/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c
index 9f766ddd946ab..753ddf79cf5e0 100644
--- a/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c
+++ b/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c
@@ -4,12 +4,29 @@
#include <test_progs.h>
#include <bpf/btf.h>
+static int find_type_in_ctx_convert(struct btf *btf,
+ const char *prog_type_name,
+ const struct btf_type *t)
+{
+ const struct btf_member *m;
+ size_t cmplen = strlen(prog_type_name);
+ int i, n;
+
+ for (m = btf_members(t), i = 0, n = btf_vlen(t); i < n; m++, i++) {
+ const char *member_name = btf__str_by_offset(btf, m->name_off);
+
+ if (!strncmp(prog_type_name, member_name, cmplen))
+ return 1;
+ }
+ return 0;
+}
+
void test_libbpf_probe_prog_types(void)
{
struct btf *btf;
- const struct btf_type *t;
+ const struct btf_type *t, *context_convert_t;
const struct btf_enum *e;
- int i, n, id;
+ int i, n, id, context_convert_id;
btf = btf__parse("/sys/kernel/btf/vmlinux", NULL);
if (!ASSERT_OK_PTR(btf, "btf_parse"))
@@ -23,6 +40,14 @@ void test_libbpf_probe_prog_types(void)
if (!ASSERT_OK_PTR(t, "bpf_prog_type_enum"))
goto cleanup;
+ context_convert_id = btf__find_by_name_kind(btf, "bpf_ctx_convert",
+ BTF_KIND_STRUCT);
+ if (!ASSERT_GT(context_convert_id, 0, "bpf_ctx_convert_id"))
+ goto cleanup;
+ context_convert_t = btf__type_by_id(btf, context_convert_id);
+ if (!ASSERT_OK_PTR(t, "bpf_ctx_convert_type"))
+ goto cleanup;
+
for (e = btf_enum(t), i = 0, n = btf_vlen(t); i < n; e++, i++) {
const char *prog_type_name = btf__str_by_offset(btf, e->name_off);
enum bpf_prog_type prog_type = (enum bpf_prog_type)e->val;
@@ -31,6 +56,10 @@ void test_libbpf_probe_prog_types(void)
if (prog_type == BPF_PROG_TYPE_UNSPEC)
continue;
+ if (!find_type_in_ctx_convert(btf, prog_type_name,
+ context_convert_t))
+ continue;
+
if (!test__start_subtest(prog_type_name))
continue;
--
2.37.3On Fri, Sep 30, 2022 at 4:09 AM Artem Savkov <asavkov@redhat.com> wrote:
>
> At the moment libbpf_probe_prog_types test iterates over all available
> BPF_PROG_TYPE regardless of kernel configuration which can exclude some
> of those. Unfortunately there is no direct way to tell which types are
> available, but we can look at struct bpf_ctx_onvert to tell which ones
> are available.
>
> Signed-off-by: Artem Savkov <asavkov@redhat.com>
> ---
Many selftests assume correct kernel configuration which is encoded in
config and config.<arch> files. So it seems fair to assume that all
defined program types are available on kernel-under-test.
If someone is running selftests under custom more minimal kernel they
can use denylist to ignore specific prog type subtests?
> .../selftests/bpf/prog_tests/libbpf_probes.c | 33 +++++++++++++++++--
> 1 file changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c b/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c
> index 9f766ddd946ab..753ddf79cf5e0 100644
> --- a/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c
> +++ b/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c
> @@ -4,12 +4,29 @@
> #include <test_progs.h>
> #include <bpf/btf.h>
>
> +static int find_type_in_ctx_convert(struct btf *btf,
> + const char *prog_type_name,
> + const struct btf_type *t)
> +{
> + const struct btf_member *m;
> + size_t cmplen = strlen(prog_type_name);
> + int i, n;
> +
> + for (m = btf_members(t), i = 0, n = btf_vlen(t); i < n; m++, i++) {
> + const char *member_name = btf__str_by_offset(btf, m->name_off);
> +
> + if (!strncmp(prog_type_name, member_name, cmplen))
> + return 1;
> + }
> + return 0;
> +}
> +
> void test_libbpf_probe_prog_types(void)
> {
> struct btf *btf;
> - const struct btf_type *t;
> + const struct btf_type *t, *context_convert_t;
> const struct btf_enum *e;
> - int i, n, id;
> + int i, n, id, context_convert_id;
>
> btf = btf__parse("/sys/kernel/btf/vmlinux", NULL);
> if (!ASSERT_OK_PTR(btf, "btf_parse"))
> @@ -23,6 +40,14 @@ void test_libbpf_probe_prog_types(void)
> if (!ASSERT_OK_PTR(t, "bpf_prog_type_enum"))
> goto cleanup;
>
> + context_convert_id = btf__find_by_name_kind(btf, "bpf_ctx_convert",
> + BTF_KIND_STRUCT);
> + if (!ASSERT_GT(context_convert_id, 0, "bpf_ctx_convert_id"))
> + goto cleanup;
> + context_convert_t = btf__type_by_id(btf, context_convert_id);
> + if (!ASSERT_OK_PTR(t, "bpf_ctx_convert_type"))
> + goto cleanup;
> +
> for (e = btf_enum(t), i = 0, n = btf_vlen(t); i < n; e++, i++) {
> const char *prog_type_name = btf__str_by_offset(btf, e->name_off);
> enum bpf_prog_type prog_type = (enum bpf_prog_type)e->val;
> @@ -31,6 +56,10 @@ void test_libbpf_probe_prog_types(void)
> if (prog_type == BPF_PROG_TYPE_UNSPEC)
> continue;
>
> + if (!find_type_in_ctx_convert(btf, prog_type_name,
> + context_convert_t))
> + continue;
> +
> if (!test__start_subtest(prog_type_name))
> continue;
>
> --
> 2.37.3
>
On Fri, Sep 30, 2022 at 04:06:41PM -0700, Andrii Nakryiko wrote: > On Fri, Sep 30, 2022 at 4:09 AM Artem Savkov <asavkov@redhat.com> wrote: > > > > At the moment libbpf_probe_prog_types test iterates over all available > > BPF_PROG_TYPE regardless of kernel configuration which can exclude some > > of those. Unfortunately there is no direct way to tell which types are > > available, but we can look at struct bpf_ctx_onvert to tell which ones > > are available. > > > > Signed-off-by: Artem Savkov <asavkov@redhat.com> > > --- > > Many selftests assume correct kernel configuration which is encoded in > config and config.<arch> files. So it seems fair to assume that all > defined program types are available on kernel-under-test. Ok. Wasn't sure if this is the assumption being made. > If someone is running selftests under custom more minimal kernel they > can use denylist to ignore specific prog type subtests? Thanks for the suggestion. Denylist is a bit too broad in this case as it means we'll be disabling the whole libbpf_probe_prog_types test while only a single type is a problem. Looks like we'll have to live with a downstream-only patch in this case. -- Artem
On Sun, Oct 2, 2022 at 11:56 PM Artem Savkov <asavkov@redhat.com> wrote: > > On Fri, Sep 30, 2022 at 04:06:41PM -0700, Andrii Nakryiko wrote: > > On Fri, Sep 30, 2022 at 4:09 AM Artem Savkov <asavkov@redhat.com> wrote: > > > > > > At the moment libbpf_probe_prog_types test iterates over all available > > > BPF_PROG_TYPE regardless of kernel configuration which can exclude some > > > of those. Unfortunately there is no direct way to tell which types are > > > available, but we can look at struct bpf_ctx_onvert to tell which ones > > > are available. > > > > > > Signed-off-by: Artem Savkov <asavkov@redhat.com> > > > --- > > > > Many selftests assume correct kernel configuration which is encoded in > > config and config.<arch> files. So it seems fair to assume that all > > defined program types are available on kernel-under-test. > > Ok. Wasn't sure if this is the assumption being made. > > > If someone is running selftests under custom more minimal kernel they > > can use denylist to ignore specific prog type subtests? > > Thanks for the suggestion. Denylist is a bit too broad in this case as > it means we'll be disabling the whole libbpf_probe_prog_types test while > only a single type is a problem. Looks like we'll have to live with a > downstream-only patch in this case. Allow/deny lists allow to specify subtests as well, so you can have very granular control. E.g., [vmuser@archvm bpf]$ sudo ./test_progs -a 'libbpf_probe_prog_types/*SK*' Failed to load bpf_testmod.ko into the kernel: -22 WARNING! Selftests relying on bpf_testmod.ko will be skipped. #96/8 libbpf_probe_prog_types/BPF_PROG_TYPE_CGROUP_SKB:OK #96/14 libbpf_probe_prog_types/BPF_PROG_TYPE_SK_SKB:OK #96/16 libbpf_probe_prog_types/BPF_PROG_TYPE_SK_MSG:OK #96/21 libbpf_probe_prog_types/BPF_PROG_TYPE_SK_REUSEPORT:OK #96/30 libbpf_probe_prog_types/BPF_PROG_TYPE_SK_LOOKUP:OK #96 libbpf_probe_prog_types:OK Summary: 1/5 PASSED, 0 SKIPPED, 0 FAILED As you can see each program type is a subtest, so you can pick and choose which ones to run. > > -- > Artem >
On Mon, Oct 03, 2022 at 05:03:18PM -0700, Andrii Nakryiko wrote: > On Sun, Oct 2, 2022 at 11:56 PM Artem Savkov <asavkov@redhat.com> wrote: > > > > On Fri, Sep 30, 2022 at 04:06:41PM -0700, Andrii Nakryiko wrote: > > > On Fri, Sep 30, 2022 at 4:09 AM Artem Savkov <asavkov@redhat.com> wrote: > > > > > > > > At the moment libbpf_probe_prog_types test iterates over all available > > > > BPF_PROG_TYPE regardless of kernel configuration which can exclude some > > > > of those. Unfortunately there is no direct way to tell which types are > > > > available, but we can look at struct bpf_ctx_onvert to tell which ones > > > > are available. > > > > > > > > Signed-off-by: Artem Savkov <asavkov@redhat.com> > > > > --- > > > > > > Many selftests assume correct kernel configuration which is encoded in > > > config and config.<arch> files. So it seems fair to assume that all > > > defined program types are available on kernel-under-test. > > > > Ok. Wasn't sure if this is the assumption being made. > > > > > If someone is running selftests under custom more minimal kernel they > > > can use denylist to ignore specific prog type subtests? > > > > Thanks for the suggestion. Denylist is a bit too broad in this case as > > it means we'll be disabling the whole libbpf_probe_prog_types test while > > only a single type is a problem. Looks like we'll have to live with a > > downstream-only patch in this case. > > Allow/deny lists allow to specify subtests as well, so you can have > very granular control. E.g., > > [vmuser@archvm bpf]$ sudo ./test_progs -a 'libbpf_probe_prog_types/*SK*' > Failed to load bpf_testmod.ko into the kernel: -22 > WARNING! Selftests relying on bpf_testmod.ko will be skipped. > #96/8 libbpf_probe_prog_types/BPF_PROG_TYPE_CGROUP_SKB:OK > #96/14 libbpf_probe_prog_types/BPF_PROG_TYPE_SK_SKB:OK > #96/16 libbpf_probe_prog_types/BPF_PROG_TYPE_SK_MSG:OK > #96/21 libbpf_probe_prog_types/BPF_PROG_TYPE_SK_REUSEPORT:OK > #96/30 libbpf_probe_prog_types/BPF_PROG_TYPE_SK_LOOKUP:OK > #96 libbpf_probe_prog_types:OK > Summary: 1/5 PASSED, 0 SKIPPED, 0 FAILED > > > As you can see each program type is a subtest, so you can pick and > choose which ones to run. Right, didn't know it can do that. Thanks for the pointer. -- Artem
On Fri, Sep 30, 2022 at 01:09:00PM +0200, Artem Savkov wrote:
> At the moment libbpf_probe_prog_types test iterates over all available
> BPF_PROG_TYPE regardless of kernel configuration which can exclude some
> of those. Unfortunately there is no direct way to tell which types are
> available, but we can look at struct bpf_ctx_onvert to tell which ones
> are available.
>
> Signed-off-by: Artem Savkov <asavkov@redhat.com>
> ---
> .../selftests/bpf/prog_tests/libbpf_probes.c | 33 +++++++++++++++++--
> 1 file changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c b/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c
> index 9f766ddd946ab..753ddf79cf5e0 100644
> --- a/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c
> +++ b/tools/testing/selftests/bpf/prog_tests/libbpf_probes.c
> @@ -4,12 +4,29 @@
> #include <test_progs.h>
> #include <bpf/btf.h>
>
> +static int find_type_in_ctx_convert(struct btf *btf,
> + const char *prog_type_name,
> + const struct btf_type *t)
> +{
> + const struct btf_member *m;
> + size_t cmplen = strlen(prog_type_name);
> + int i, n;
> +
> + for (m = btf_members(t), i = 0, n = btf_vlen(t); i < n; m++, i++) {
> + const char *member_name = btf__str_by_offset(btf, m->name_off);
> +
> + if (!strncmp(prog_type_name, member_name, cmplen))
> + return 1;
> + }
> + return 0;
> +}
> +
> void test_libbpf_probe_prog_types(void)
> {
> struct btf *btf;
> - const struct btf_type *t;
> + const struct btf_type *t, *context_convert_t;
> const struct btf_enum *e;
> - int i, n, id;
> + int i, n, id, context_convert_id;
>
> btf = btf__parse("/sys/kernel/btf/vmlinux", NULL);
> if (!ASSERT_OK_PTR(btf, "btf_parse"))
> @@ -23,6 +40,14 @@ void test_libbpf_probe_prog_types(void)
> if (!ASSERT_OK_PTR(t, "bpf_prog_type_enum"))
> goto cleanup;
>
> + context_convert_id = btf__find_by_name_kind(btf, "bpf_ctx_convert",
> + BTF_KIND_STRUCT);
> + if (!ASSERT_GT(context_convert_id, 0, "bpf_ctx_convert_id"))
> + goto cleanup;
> + context_convert_t = btf__type_by_id(btf, context_convert_id);
> + if (!ASSERT_OK_PTR(t, "bpf_ctx_convert_type"))
ASSERT_OK_PTR should check context_convert_t ?
I wonder if we could traverse bpf_ctx_convert members directly
instead of bpf_prog_type enum, but maybe there'd be other issues
jirka
> + goto cleanup;
> +
> for (e = btf_enum(t), i = 0, n = btf_vlen(t); i < n; e++, i++) {
> const char *prog_type_name = btf__str_by_offset(btf, e->name_off);
> enum bpf_prog_type prog_type = (enum bpf_prog_type)e->val;
> @@ -31,6 +56,10 @@ void test_libbpf_probe_prog_types(void)
> if (prog_type == BPF_PROG_TYPE_UNSPEC)
> continue;
>
> + if (!find_type_in_ctx_convert(btf, prog_type_name,
> + context_convert_t))
> + continue;
> +
> if (!test__start_subtest(prog_type_name))
> continue;
>
> --
> 2.37.3
>
© 2016 - 2026 Red Hat, Inc.