From: Jiri Olsa <olsajiri@gmail.com>
To: David Vernet <void@manifault.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, Martin KaFai Lau <kafai@fb.com>,
Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@chromium.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Artem Savkov <asavkov@redhat.com>
Subject: Re: [PATCHv3 bpf-next 2/9] selftests/bpf: Move test_progs helpers to testing_helpers object
Date: Wed, 8 Feb 2023 10:35:28 +0100 [thread overview]
Message-ID: <Y+Ns4DHVv758IjkT@krava> (raw)
In-Reply-To: <Y+JiUQFyalc0aV6M@maniforge.lan>
On Tue, Feb 07, 2023 at 08:38:09AM -0600, David Vernet wrote:
> On Fri, Feb 03, 2023 at 05:23:29PM +0100, Jiri Olsa wrote:
> > Moving test_progs helpers to testing_helpers object so they can be
> > used from test_verifier in following changes.
> >
> > Also adding missing ifndef header guard to testing_helpers.h header.
> >
> > Using stderr instead of env.stderr because un/load_bpf_testmod helpers
> > will be used outside test_progs. Also at the point of calling them
> > in test_progs the std files are not hijacked yet and stderr is the
> > same as env.stderr.
>
> Makes sense. Possibly something to clean up at another time but given
> that we were being inconsistent with env.stdout and env.stderr in
> load_bpf_testmod() in the first place, this seems totally fine.
ok
>
> Acked-by: David Vernet <void@manifault.com>
>
> Left one question about kern_sync_rcu() below that need not block this
> patch series, and can be addressed in a follow-up if it's even relevant.
SNIP
> > +void unload_bpf_testmod(bool verbose)
> > +{
> > + if (kern_sync_rcu())
> > + fprintf(stderr, "Failed to trigger kernel-side RCU sync!\n");
>
> I realize there's no behavior change here, but out of curiosity, do you
> know why we need a synchronize_rcu() here? In general this feels kind of
> sketchy, and like something we should just put in bpf_testmod_exit() if
> it's really needed for something in the kernel.
it's explained in here:
635599bace25 selftests/bpf: Sync RCU before unloading bpf_testmod
If some of the subtests use module BTFs through ksyms, they will cause
bpf_prog to take a refcount on bpf_testmod module, which will prevent it from
successfully unloading. Module's refcnt is decremented when bpf_prog is freed,
which generally happens in RCU callback. So we need to trigger
syncronize_rcu() in the kernel, which can be achieved nicely with
membarrier(MEMBARRIER_CMD_SHARED) or membarrier(MEMBARRIER_CMD_GLOBAL) syscall.
So do that in kernel_sync_rcu() and make it available to other test inside the
test_progs. This synchronize_rcu() is called before attempting to unload
bpf_testmod.
jirka
>
> > + if (delete_module("bpf_testmod", 0)) {
> > + if (errno == ENOENT) {
> > + if (verbose)
> > + fprintf(stdout, "bpf_testmod.ko is already unloaded.\n");
> > + return;
> > + }
> > + fprintf(stderr, "Failed to unload bpf_testmod.ko from kernel: %d\n", -errno);
> > + return;
> > + }
> > + if (verbose)
> > + fprintf(stdout, "Successfully unloaded bpf_testmod.ko.\n");
> > +}
> > +
SNIP
next prev parent reply other threads:[~2023-02-08 9:35 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-03 16:23 [PATCHv3 bpf-next 0/9] bpf: Move kernel test kfuncs into bpf_testmod Jiri Olsa
2023-02-03 16:23 ` [PATCHv3 bpf-next 1/9] selftests/bpf: Move kfunc exports to bpf_testmod/bpf_testmod_kfunc.h Jiri Olsa
2023-02-07 14:28 ` David Vernet
2023-02-09 0:20 ` Andrii Nakryiko
2023-02-09 8:45 ` Jiri Olsa
2023-02-03 16:23 ` [PATCHv3 bpf-next 2/9] selftests/bpf: Move test_progs helpers to testing_helpers object Jiri Olsa
2023-02-07 14:38 ` David Vernet
2023-02-08 9:35 ` Jiri Olsa [this message]
2023-02-03 16:23 ` [PATCHv3 bpf-next 3/9] selftests/bpf: Use only stdout in un/load_bpf_testmod functions Jiri Olsa
2023-02-07 14:41 ` David Vernet
2023-02-08 9:44 ` Jiri Olsa
2023-02-03 16:23 ` [PATCHv3 bpf-next 4/9] selftests/bpf: Do not unload bpf_testmod in load_bpf_testmod Jiri Olsa
2023-02-03 16:23 ` [PATCHv3 bpf-next 5/9] selftests/bpf: Use un/load_bpf_testmod functions in tests Jiri Olsa
2023-02-07 14:45 ` David Vernet
2023-02-03 16:23 ` [PATCHv3 bpf-next 6/9] selftests/bpf: Load bpf_testmod for verifier test Jiri Olsa
2023-02-07 14:46 ` David Vernet
2023-02-03 16:23 ` [PATCHv3 bpf-next 7/9] selftests/bpf: Allow to use kfunc from testmod.ko in test_verifier Jiri Olsa
2023-02-07 15:34 ` David Vernet
2023-02-08 10:09 ` Jiri Olsa
2023-02-03 16:23 ` [PATCHv3 bpf-next 8/9] selftests/bpf: Remove extern from kfuncs declarations Jiri Olsa
2023-02-07 15:35 ` David Vernet
2023-02-03 16:23 ` [PATCHv3 bpf-next 9/9] bpf: Move kernel test kfuncs to bpf_testmod Jiri Olsa
2023-02-04 9:21 ` [PATCHv3 bpf-next 0/9] bpf: Move kernel test kfuncs into bpf_testmod Alexei Starovoitov
2023-02-05 18:17 ` Jiri Olsa
2023-02-05 18:36 ` Ilya Leoshkevich
2023-02-06 9:15 ` Jiri Olsa
2023-02-09 8:47 ` Jiri Olsa
2023-02-09 9:38 ` Ilya Leoshkevich
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=Y+Ns4DHVv758IjkT@krava \
--to=olsajiri@gmail.com \
--cc=andrii@kernel.org \
--cc=asavkov@redhat.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=memxor@gmail.com \
--cc=sdf@google.com \
--cc=songliubraving@fb.com \
--cc=void@manifault.com \
--cc=yhs@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.