All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Lorenz Bauer <lmb@cloudflare.com>,
	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 1/5] selftests/bpf: add remaining ASSERT_xxx() variants
Date: Mon, 26 Apr 2021 09:15:07 -0700	[thread overview]
Message-ID: <CAEf4BzYixzoqzE_c+sd7QoQDg8dGaKf_UBf06AqTmCdUagoJvg@mail.gmail.com> (raw)
In-Reply-To: <875z09ca0p.fsf@toke.dk>

On Mon, Apr 26, 2021 at 8:59 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
>
> > On Mon, Apr 26, 2021 at 1:06 AM Lorenz Bauer <lmb@cloudflare.com> wrote:
> >>
> >> On Sat, 24 Apr 2021 at 00:36, Andrii Nakryiko <andrii@kernel.org> wrote:
> >> >
> >> > Add ASSERT_TRUE/ASSERT_FALSE for conditions calculated with custom logic to
> >> > true/false. Also add remaining arithmetical assertions:
> >> >   - ASSERT_LE -- less than or equal;
> >> >   - ASSERT_GT -- greater than;
> >> >   - ASSERT_GE -- greater than or equal.
> >> > This should cover most scenarios where people fall back to error-prone
> >> > CHECK()s.
> >> >
> >> > Also extend ASSERT_ERR() to print out errno, in addition to direct error.
> >> >
> >> > Also convert few CHECK() instances to ensure new ASSERT_xxx() variants work as
> >> > expected. Subsequent patch will also use ASSERT_TRUE/ASSERT_FALSE more
> >> > extensively.
> >> >
> >> > Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> >> > ---
> >> >  .../selftests/bpf/prog_tests/btf_dump.c       |  2 +-
> >> >  .../selftests/bpf/prog_tests/btf_endian.c     |  4 +-
> >> >  .../selftests/bpf/prog_tests/cgroup_link.c    |  2 +-
> >> >  .../selftests/bpf/prog_tests/kfree_skb.c      |  2 +-
> >> >  .../selftests/bpf/prog_tests/resolve_btfids.c |  7 +--
> >> >  .../selftests/bpf/prog_tests/snprintf_btf.c   |  4 +-
> >> >  tools/testing/selftests/bpf/test_progs.h      | 50 ++++++++++++++++++-
> >> >  7 files changed, 56 insertions(+), 15 deletions(-)
> >> >
> >> > diff --git a/tools/testing/selftests/bpf/prog_tests/btf_dump.c b/tools/testing/selftests/bpf/prog_tests/btf_dump.c
> >> > index c60091ee8a21..5e129dc2073c 100644
> >> > --- a/tools/testing/selftests/bpf/prog_tests/btf_dump.c
> >> > +++ b/tools/testing/selftests/bpf/prog_tests/btf_dump.c
> >> > @@ -77,7 +77,7 @@ static int test_btf_dump_case(int n, struct btf_dump_test_case *t)
> >> >
> >> >         snprintf(out_file, sizeof(out_file), "/tmp/%s.output.XXXXXX", t->file);
> >> >         fd = mkstemp(out_file);
> >> > -       if (CHECK(fd < 0, "create_tmp", "failed to create file: %d\n", fd)) {
> >> > +       if (!ASSERT_GE(fd, 0, "create_tmp")) {
> >>
> >> Nit: I would find ASSERT_LE easier to read here. Inverting boolean
> >> conditions is easy to get wrong.
> >
> > You mean if (ASSERT_LE(fd, -1, "create_tmp")) { err = fd; goto done; } ?
> >
> > That will mark the test failing if fd >= 0, which is exactly opposite
> > to what we wan't. It's confusing because CHECK() checks invalid
> > conditions and returns "true" if it holds. But ASSERT_xxx() checks
> > *valid* condition and returns whether valid condition holds. So the
> > pattern is always
>
> There's already an ASSERT_OK_PTR(), so maybe a corresponding
> ASSERT_OK_FD() would be handy?

I honestly don't see the point. OK_PTR is special, it checks NULL and
the special ERR_PTR() variants, which is a lot of hassle to check
manually. While for FD doing ASSERT_GE(fd, 0) seems to be fine and
just mostly natural. Also for some APIs valid FD is > 0 and for other
cases valid FD is plain >= 0, so that just adds to the confusion.

>
> -Toke
>

  reply	other threads:[~2021-04-26 16:15 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 [this message]
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

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=CAEf4BzYixzoqzE_c+sd7QoQDg8dGaKf_UBf06AqTmCdUagoJvg@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 \
    --cc=toke@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.