From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Lorenz Bauer <lmb@cloudflare.com>
Cc: Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
Networking <netdev@vger.kernel.org>,
Alexei Starovoitov <ast@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 5/5] selftests/bpf: fix core_reloc test runner
Date: Mon, 26 Apr 2021 08:55:10 -0700 [thread overview]
Message-ID: <CAEf4BzYTg+eawA9gbBM30QZpwS=wTNCpG4SsFNiLctKjChyFNg@mail.gmail.com> (raw)
In-Reply-To: <CACAyw98cvRe6rE8XOBZfd7v=_5X45U=Qb0AtWJi5Kw2hWccpFQ@mail.gmail.com>
On Mon, Apr 26, 2021 at 1:17 AM Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> On Sat, 24 Apr 2021 at 00:36, Andrii Nakryiko <andrii@kernel.org> wrote:
> >
> > Fix failed tests checks in core_reloc test runner, which allowed failing tests
> > to pass quietly. Also add extra check to make sure that expected to fail test cases with
> > invalid names are caught as test failure anyway, as this is not an expected
> > failure mode. Also fix mislabeled probed vs direct bitfield test cases.
> >
> > Fixes: 124a892d1c41 ("selftests/bpf: Test TYPE_EXISTS and TYPE_SIZE CO-RE relocations")
> > Reported-by: Lorenz Bauer <lmb@cloudflare.com>
> > Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> > ---
> > .../selftests/bpf/prog_tests/core_reloc.c | 20 +++++++++++--------
> > 1 file changed, 12 insertions(+), 8 deletions(-)
> >
> > diff --git a/tools/testing/selftests/bpf/prog_tests/core_reloc.c b/tools/testing/selftests/bpf/prog_tests/core_reloc.c
> > index 385fd7696a2e..607710826dca 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/core_reloc.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/core_reloc.c
> > @@ -217,7 +217,7 @@ static int duration = 0;
> >
> > #define BITFIELDS_CASE(name, ...) { \
> > BITFIELDS_CASE_COMMON("test_core_reloc_bitfields_probed.o", \
> > - "direct:", name), \
> > + "probed:", name), \
> > .input = STRUCT_TO_CHAR_PTR(core_reloc_##name) __VA_ARGS__, \
> > .input_len = sizeof(struct core_reloc_##name), \
> > .output = STRUCT_TO_CHAR_PTR(core_reloc_bitfields_output) \
> > @@ -225,7 +225,7 @@ static int duration = 0;
> > .output_len = sizeof(struct core_reloc_bitfields_output), \
> > }, { \
> > BITFIELDS_CASE_COMMON("test_core_reloc_bitfields_direct.o", \
> > - "probed:", name), \
> > + "direct:", name), \
> > .input = STRUCT_TO_CHAR_PTR(core_reloc_##name) __VA_ARGS__, \
> > .input_len = sizeof(struct core_reloc_##name), \
> > .output = STRUCT_TO_CHAR_PTR(core_reloc_bitfields_output) \
> > @@ -546,8 +546,7 @@ static struct core_reloc_test_case test_cases[] = {
> > ARRAYS_ERR_CASE(arrays___err_too_small),
> > ARRAYS_ERR_CASE(arrays___err_too_shallow),
> > ARRAYS_ERR_CASE(arrays___err_non_array),
> > - ARRAYS_ERR_CASE(arrays___err_wrong_val_type1),
> > - ARRAYS_ERR_CASE(arrays___err_wrong_val_type2),
> > + ARRAYS_ERR_CASE(arrays___err_wrong_val_type),
> > ARRAYS_ERR_CASE(arrays___err_bad_zero_sz_arr),
> >
> > /* enum/ptr/int handling scenarios */
> > @@ -865,13 +864,20 @@ void test_core_reloc(void)
> > "prog '%s' not found\n", probe_name))
> > goto cleanup;
> >
> > +
> > + if (test_case->btf_src_file) {
> > + err = access(test_case->btf_src_file, R_OK);
> > + if (!ASSERT_OK(err, "btf_src_file"))
> > + goto cleanup;
> > + }
> > +
> > load_attr.obj = obj;
> > load_attr.log_level = 0;
> > load_attr.target_btf_path = test_case->btf_src_file;
> > err = bpf_object__load_xattr(&load_attr);
> > if (err) {
> > if (!test_case->fails)
> > - CHECK(false, "obj_load", "failed to load prog '%s': %d\n", probe_name, err);
> > + ASSERT_OK(err, "obj_load");
> > goto cleanup;
> > }
> >
> > @@ -910,10 +916,8 @@ void test_core_reloc(void)
> > goto cleanup;
> > }
> >
> > - if (test_case->fails) {
> > - CHECK(false, "obj_load_fail", "should fail to load prog '%s'\n", probe_name);
> > + if (!ASSERT_FALSE(test_case->fails, "obj_load_should_fail"))
>
> Similar to my other comment, I find it difficult to tell when this
> triggers. Maybe it makes sense to return the status of the
> assertion (not the original value)? So if (assertion()) will be
> executed when the assertion fails? Not sure.
>
ASSERT_XXX() does return the status of assertion -- true if it holds,
false if it's violated. So false from ASSERT_xxx() means the test
already is marked failed.
Mechanically, in this case, it reads as "if we couldn't assert that
test_case->fails == false, do something about it". It's the part why
test_case->fails should be false is a bit obscure (because we
successfully loaded, but test_case is marked as should-be-failed, so
test_case->fails has to be false).
I hope it helps at least a bit.
> Acked-by: Lorenz Bauer <lmb@cloudflare.com>
>
> --
> Lorenz Bauer | Systems Engineer
> 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
>
> www.cloudflare.com
prev parent reply other threads:[~2021-04-26 15:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-23 23:30 [PATCH bpf-next 0/5] CO-RE relocation selftests fixes Andrii Nakryiko
2021-04-23 23:30 ` [PATCH bpf-next 1/5] selftests/bpf: add remaining ASSERT_xxx() variants Andrii Nakryiko
2021-04-26 8:05 ` Lorenz Bauer
2021-04-26 15:50 ` Andrii Nakryiko
2021-04-26 15:59 ` Toke Høiland-Jørgensen
2021-04-26 16:15 ` Andrii Nakryiko
2021-04-26 16:44 ` Toke Høiland-Jørgensen
2021-04-23 23:30 ` [PATCH bpf-next 2/5] libbpf: support BTF_KIND_FLOAT during type compatibility checks in CO-RE Andrii Nakryiko
2021-04-26 8:07 ` Lorenz Bauer
2021-04-23 23:30 ` [PATCH bpf-next 3/5] selftests/bpf: fix BPF_CORE_READ_BITFIELD() macro Andrii Nakryiko
2021-04-26 8:10 ` Lorenz Bauer
2021-04-23 23:30 ` [PATCH bpf-next 4/5] selftests/bpf: fix field existence CO-RE reloc tests Andrii Nakryiko
2021-04-26 8:12 ` Lorenz Bauer
2021-04-23 23:30 ` [PATCH bpf-next 5/5] selftests/bpf: fix core_reloc test runner Andrii Nakryiko
2021-04-26 8:16 ` Lorenz Bauer
2021-04-26 15:55 ` Andrii Nakryiko [this message]
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='CAEf4BzYTg+eawA9gbBM30QZpwS=wTNCpG4SsFNiLctKjChyFNg@mail.gmail.com' \
--to=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=lmb@cloudflare.com \
--cc=netdev@vger.kernel.org \
/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).