All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Song Liu <songliubraving@fb.com>
Cc: Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	Kernel Team <kernel-team@fb.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	john fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@chromium.org>
Subject: Re: [PATCH v5 bpf-next 3/3] selftests/bpf: add raw_tp_test_run
Date: Fri, 25 Sep 2020 10:31:29 -0700	[thread overview]
Message-ID: <CAEf4BzaD9=+paLnFnnCzyyFsrknyBZPfAZiF=9t6s56RL6Dhsg@mail.gmail.com> (raw)
In-Reply-To: <20200924230209.2561658-4-songliubraving@fb.com>

On Thu, Sep 24, 2020 at 4:03 PM Song Liu <songliubraving@fb.com> wrote:
>
> This test runs test_run for raw_tracepoint program. The test covers ctx
> input, retval output, and running on correct cpu.
>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---

Few suggestions below, but overall looks good to me:

Acked-by: Andrii Nakryiko <andriin@fb.com>

>  .../bpf/prog_tests/raw_tp_test_run.c          | 98 +++++++++++++++++++
>  .../bpf/progs/test_raw_tp_test_run.c          | 24 +++++
>  2 files changed, 122 insertions(+)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/raw_tp_test_run.c
>  create mode 100644 tools/testing/selftests/bpf/progs/test_raw_tp_test_run.c
>

[...]

> +
> +       err = bpf_prog_test_run_xattr(&test_attr);
> +       CHECK(err == 0, "test_run", "should fail for too small ctx\n");
> +
> +       test_attr.ctx_size_in = sizeof(args);
> +       err = bpf_prog_test_run_xattr(&test_attr);
> +       CHECK(err < 0, "test_run", "err %d\n", errno);
> +       CHECK(test_attr.retval != expected_retval, "check_retval",
> +             "expect 0x%x, got 0x%x\n", expected_retval, test_attr.retval);
> +
> +       for (i = 0; i < nr_online; i++) {
> +               if (online[i]) {

if (!online[i])
    continue;

That will reduce nestedness by one level

> +                       DECLARE_LIBBPF_OPTS(bpf_test_run_opts, opts,
> +                               .ctx_in = args,
> +                               .ctx_size_in = sizeof(args),
> +                               .flags = BPF_F_TEST_RUN_ON_CPU,
> +                               .retval = 0,
> +                               .cpu = i,
> +                       );

this declares variable, so should be at the top of the lexical scope


> +
> +                       err = bpf_prog_test_run_opts(prog_fd, &opts);
> +                       CHECK(err < 0, "test_run_opts", "err %d\n", errno);
> +                       CHECK(skel->data->on_cpu != i, "check_on_cpu",
> +                             "expect %d got %d\n", i, skel->data->on_cpu);
> +                       CHECK(opts.retval != expected_retval,
> +                             "check_retval", "expect 0x%x, got 0x%x\n",
> +                             expected_retval, opts.retval);
> +
> +                       if (i == 0) {

I agree that this looks a bit obscure. You can still re-use
DECLARE_LIBBPF_OPTS, just move it outside the loop. And then you can
just modify it in place to adjust to a particular case. And in log
output, we'll see 30+ similar success messages for the else branch,
which is indeed unnecessary.

> +                               /* invalid cpu ID should fail with ENXIO */
> +                               opts.cpu = 0xffffffff;
> +                               err = bpf_prog_test_run_opts(prog_fd, &opts);
> +                               CHECK(err != -1 || errno != ENXIO,
> +                                     "test_run_opts_fail",
> +                                     "should failed with ENXIO\n");
> +                       } else {
> +                               /* non-zero cpu w/o BPF_F_TEST_RUN_ON_CPU
> +                                * should fail with EINVAL
> +                                */
> +                               opts.flags = 0;
> +                               err = bpf_prog_test_run_opts(prog_fd, &opts);
> +                               CHECK(err != -1 || errno != EINVAL,
> +                                     "test_run_opts_fail",
> +                                     "should failed with EINVAL\n");
> +                       }
> +               }
> +       }

[...]

  parent reply	other threads:[~2020-09-25 17:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 23:02 [PATCH v5 bpf-next 0/3] enable BPF_PROG_TEST_RUN for raw_tp Song Liu
2020-09-24 23:02 ` [PATCH v5 bpf-next 1/3] bpf: enable BPF_PROG_TEST_RUN for raw_tracepoint Song Liu
2020-09-25 17:21   ` Andrii Nakryiko
2020-09-24 23:02 ` [PATCH v5 bpf-next 2/3] libbpf: support test run of raw tracepoint programs Song Liu
2020-09-25 17:22   ` Andrii Nakryiko
2020-09-24 23:02 ` [PATCH v5 bpf-next 3/3] selftests/bpf: add raw_tp_test_run Song Liu
2020-09-25  1:01   ` John Fastabend
2020-09-25  3:01     ` Song Liu
2020-09-25 17:31   ` Andrii Nakryiko [this message]
2020-09-25 19:49     ` Song Liu

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='CAEf4BzaD9=+paLnFnnCzyyFsrknyBZPfAZiF=9t6s56RL6Dhsg@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.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.