From: David Vernet <void@manifault.com>
To: Dave Marchevsky <davemarchevsky@meta.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Dave Marchevsky <davemarchevsky@fb.com>,
bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@kernel.org>,
Kernel Team <kernel-team@fb.com>, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH bpf-next] selftests/bpf: Add -Wuninitialized flag to bpf prog flags
Date: Thu, 2 Mar 2023 17:50:51 -0600 [thread overview]
Message-ID: <ZAE2W68Iw74A0xpK@maniforge> (raw)
In-Reply-To: <1e35323c-0383-4d5a-0027-83b9e7d1e57b@meta.com>
On Thu, Mar 02, 2023 at 06:41:55PM -0500, Dave Marchevsky wrote:
> On 3/2/23 6:29 PM, David Vernet wrote:
> > On Thu, Mar 02, 2023 at 03:23:22PM -0800, Alexei Starovoitov wrote:
> >> On Thu, Mar 2, 2023 at 3:19 PM Dave Marchevsky <davemarchevsky@fb.com> wrote:
> >>>
> >>> --- a/tools/testing/selftests/bpf/progs/rbtree_fail.c
> >>> +++ b/tools/testing/selftests/bpf/progs/rbtree_fail.c
> >>> @@ -232,8 +232,9 @@ long rbtree_api_first_release_unlock_escape(void *ctx)
> >>>
> >>> bpf_spin_lock(&glock);
> >>> res = bpf_rbtree_first(&groot);
> >>> - if (res)
> >>> - n = container_of(res, struct node_data, node);
> >>> + if (!res)
> >>> + return -1;
> >>
> >> The verifier cannot be ok with this return... I hope...
> >
> > This is a negative testcase which correctly fails, though the error
> > message wasn't what I was expecting to see:
> >
> > __failure __msg("rbtree_remove node input must be non-owning ref")
> >
> > Something about the lock still being held seems much more intuitive.
> >
>
> It's necessary to call bpf_rbtree_remove w/ lock held. This test expects
> to fail because non-owning ref "n" is clobbered after the critical
> section where it's returned by bpf_rbtree_first ends.
Oh, I see. I think that would arguably be a bit more clear if we added a
bpf_spin_unlock() to that return case then. Ideally for a negative test
we can keep the number of bugs being tested to 1. I assume that was
Alexei's point, which clearly went over my head.
>
> >>
> >>> + n = container_of(res, struct node_data, node);
> >>> bpf_spin_unlock(&glock);
next prev parent reply other threads:[~2023-03-02 23:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-02 23:19 [PATCH bpf-next] selftests/bpf: Add -Wuninitialized flag to bpf prog flags Dave Marchevsky
2023-03-02 23:23 ` Alexei Starovoitov
2023-03-02 23:29 ` David Vernet
2023-03-02 23:41 ` Dave Marchevsky
2023-03-02 23:50 ` David Vernet [this message]
2023-03-02 23:37 ` Dave Marchevsky
2023-03-02 23:27 ` David Vernet
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=ZAE2W68Iw74A0xpK@maniforge \
--to=void@manifault.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davemarchevsky@fb.com \
--cc=davemarchevsky@meta.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=tj@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