From: Stanislav Fomichev <sdf@fomichev.me>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Stanislav Fomichev <sdf@google.com>,
netdev@vger.kernel.org, davem@davemloft.net, ast@kernel.org,
daniel@iogearbox.net
Subject: Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF
Date: Wed, 12 Dec 2018 11:24:39 -0800 [thread overview]
Message-ID: <20181212192439.GE9107@mini-arch.hsd1.ca.comcast.net> (raw)
In-Reply-To: <20181212190419.kugi4cp5j5i3tbiz@ast-mbp.dhcp.thefacebook.com>
On 12/12, Alexei Starovoitov wrote:
> On Wed, Dec 12, 2018 at 10:59:13AM -0800, Stanislav Fomichev wrote:
> > On 12/12, Alexei Starovoitov wrote:
> > > On Wed, Dec 12, 2018 at 10:27:24AM -0800, Stanislav Fomichev wrote:
> > > > The following prog types don't make sense without bpf cgroup:
> > > > * BPF_PROG_TYPE_CGROUP_SKB
> > > > * BPF_PROG_TYPE_CGROUP_SOCK
> > > > * BPF_PROG_TYPE_CGROUP_SOCK_ADDR
> > > >
> > > > Skip running verifier tests that exercise these prog types if
> > > > kernel is built without proper support.
> > > >
> > > > See commit e5c504858a18 ("selftests/bpf: skip verifier sockmap tests
> > > > on kernels without support") for original motivation.
> > > >
> > > > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > > > ---
> > > > tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
> > > > 1 file changed, 35 insertions(+)
> > > >
> > > > diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> > > > index f5015566ae1b..b5470a399996 100644
> > > > --- a/tools/testing/selftests/bpf/test_verifier.c
> > > > +++ b/tools/testing/selftests/bpf/test_verifier.c
> > > > @@ -44,6 +44,7 @@
> > > > /* fallback to all features enabled */
> > > > # define CONFIG_BPF_STREAM_PARSER 1
> > > > # define CONFIG_XDP_SOCKETS 1
> > > > +# define CONFIG_CGROUP_BPF 1
> > >
> > > I really don't like where these is going.
> > > I think previous set should be reverted.
> > > This is not a scalable approach.
> > > Use libbpf probing approach to check whether feature is present instead.
> > I can probably add runtime probing instead of depending on compile-time
> > config, but I think that we would still need some per-test mechanism
> > to say that it depends on feature X (per-test .config_disabled or
> > similar).
> > Will moving these checks to runtime address your concern? (there is sill a
> > scalability issue though)
>
> you said it youself. config_disabled doesn't scale.
> hence it's not a solution regardless of macro or runtime probing.
Let me see if I can use per-test prog_type for this type of probing.
Load 'return 0' program per-prog_type and use it as an indication of
runtime support. This should probably work in the majority of the cases.
I'll get back to you shortly.
next prev parent reply other threads:[~2018-12-12 19:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-12 18:27 [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF Stanislav Fomichev
2018-12-12 18:27 ` [PATCH bpf-next 2/2] selftests/bpf: skip verifier tests that depend on CONFIG_BPF_EVENTS Stanislav Fomichev
2018-12-12 18:51 ` [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF Alexei Starovoitov
2018-12-12 18:59 ` Stanislav Fomichev
2018-12-12 19:04 ` Alexei Starovoitov
2018-12-12 19:24 ` Stanislav Fomichev [this message]
2018-12-12 19:54 ` Stanislav Fomichev
2018-12-12 20:13 ` Alexei Starovoitov
2018-12-12 21:23 ` Edward Cree
2018-12-12 22:07 ` Alexei Starovoitov
2018-12-12 22:32 ` Stanislav Fomichev
2018-12-13 6:06 ` Alexei Starovoitov
2018-12-13 11:52 ` Daniel Borkmann
2018-12-13 12:18 ` Quentin Monnet
2018-12-13 16:37 ` Stanislav Fomichev
2018-12-13 17:02 ` Quentin Monnet
2018-12-13 17:10 ` Stanislav Fomichev
2018-12-14 11:43 ` Quentin Monnet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181212192439.GE9107@mini-arch.hsd1.ca.comcast.net \
--to=sdf@fomichev.me \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=sdf@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).