From: Jakub Sitnicki <jakub@cloudflare.com>
To: Andrii Nakryiko <andriin@fb.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, ast@fb.com,
daniel@iogearbox.net, andrii.nakryiko@gmail.com,
kernel-team@fb.com, Jiri Olsa <jolsa@kernel.org>
Subject: Re: [PATCH bpf-next] selftests/bpf: fix trampoline_count clean up logic
Date: Fri, 21 Feb 2020 10:21:51 +0000 [thread overview]
Message-ID: <87eeuo5jgg.fsf@cloudflare.com> (raw)
In-Reply-To: <20200220230546.769250-1-andriin@fb.com>
On Thu, Feb 20, 2020 at 11:05 PM GMT, Andrii Nakryiko wrote:
> Libbpf's Travis CI tests caught this issue. Ensure bpf_link and bpf_object
> clean up is performed correctly.
>
> Fixes: d633d57902a5 ("selftest/bpf: Add test for allowed trampolines count")
> Cc: Jiri Olsa <jolsa@kernel.org>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> .../bpf/prog_tests/trampoline_count.c | 25 +++++++++++++------
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/trampoline_count.c b/tools/testing/selftests/bpf/prog_tests/trampoline_count.c
> index 1f6ccdaed1ac..781c8d11604b 100644
> --- a/tools/testing/selftests/bpf/prog_tests/trampoline_count.c
> +++ b/tools/testing/selftests/bpf/prog_tests/trampoline_count.c
> @@ -55,31 +55,40 @@ void test_trampoline_count(void)
> /* attach 'allowed' 40 trampoline programs */
> for (i = 0; i < MAX_TRAMP_PROGS; i++) {
> obj = bpf_object__open_file(object, NULL);
> - if (CHECK(IS_ERR(obj), "obj_open_file", "err %ld\n", PTR_ERR(obj)))
> + if (CHECK(IS_ERR(obj), "obj_open_file", "err %ld\n", PTR_ERR(obj))) {
> + obj = NULL;
> goto cleanup;
> + }
>
> err = bpf_object__load(obj);
> if (CHECK(err, "obj_load", "err %d\n", err))
> goto cleanup;
> inst[i].obj = obj;
> + obj = NULL;
>
> if (rand() % 2) {
> - link = load(obj, fentry_name);
> - if (CHECK(IS_ERR(link), "attach prog", "err %ld\n", PTR_ERR(link)))
> + link = load(inst[i].obj, fentry_name);
> + if (CHECK(IS_ERR(link), "attach prog", "err %ld\n", PTR_ERR(link))) {
> + link = NULL;
> goto cleanup;
> + }
> inst[i].link_fentry = link;
> } else {
> - link = load(obj, fexit_name);
> - if (CHECK(IS_ERR(link), "attach prog", "err %ld\n", PTR_ERR(link)))
> + link = load(inst[i].obj, fexit_name);
> + if (CHECK(IS_ERR(link), "attach prog", "err %ld\n", PTR_ERR(link))) {
> + link = NULL;
> goto cleanup;
> + }
> inst[i].link_fexit = link;
> }
> }
>
> /* and try 1 extra.. */
> obj = bpf_object__open_file(object, NULL);
> - if (CHECK(IS_ERR(obj), "obj_open_file", "err %ld\n", PTR_ERR(obj)))
> + if (CHECK(IS_ERR(obj), "obj_open_file", "err %ld\n", PTR_ERR(obj))) {
> + obj = NULL;
> goto cleanup;
> + }
>
> err = bpf_object__load(obj);
> if (CHECK(err, "obj_load", "err %d\n", err))
> @@ -104,7 +113,9 @@ void test_trampoline_count(void)
> cleanup_extra:
> bpf_object__close(obj);
> cleanup:
> - while (--i) {
> + if (i >= MAX_TRAMP_PROGS)
> + i = MAX_TRAMP_PROGS - 1;
> + for (; i >= 0; i--) {
> bpf_link__destroy(inst[i].link_fentry);
> bpf_link__destroy(inst[i].link_fexit);
> bpf_object__close(inst[i].obj);
I'm not sure I'm grasping what the fix is about.
We don't access obj or link from cleanup, so what is the point of
setting them to NULL before jumping there?
Or is it all just an ancillary change to clamping the loop index
variable to (MAX_TRAMP_PROGS - 1)?
next prev parent reply other threads:[~2020-02-21 10:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 23:05 [PATCH bpf-next] selftests/bpf: fix trampoline_count clean up logic Andrii Nakryiko
2020-02-21 2:04 ` Alexei Starovoitov
2020-02-21 2:06 ` Song Liu
2020-02-21 4:20 ` Andrii Nakryiko
2020-02-21 4:31 ` Song Liu
2020-02-21 4:45 ` Andrii Nakryiko
2020-02-21 10:21 ` Jakub Sitnicki [this message]
2020-02-22 0:21 ` Andrii Nakryiko
2020-02-21 13:04 ` Jiri Olsa
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=87eeuo5jgg.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jolsa@kernel.org \
--cc=kernel-team@fb.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).