From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
Daniel Borkmann <daniel@iogearbox.net>,
Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH RFC v3 bpf-next 1/4] bpf: Introduce sleepable BPF programs
Date: Thu, 11 Jun 2020 19:13:01 -0700 [thread overview]
Message-ID: <20200612021301.7esez3plqpmjf5wu@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20200612000447.GF4455@paulmck-ThinkPad-P72>
On Thu, Jun 11, 2020 at 05:04:47PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 11, 2020 at 03:29:09PM -0700, Alexei Starovoitov wrote:
> > On Thu, Jun 11, 2020 at 3:23 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > /* dummy _ops. The verifier will operate on target program's ops. */
> > > const struct bpf_verifier_ops bpf_extension_verifier_ops = {
> > > @@ -205,14 +206,12 @@ static int bpf_trampoline_update(struct bpf_trampoline *tr)
> > > tprogs[BPF_TRAMP_MODIFY_RETURN].nr_progs)
> > > flags = BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_SKIP_FRAME;
> > >
> > > - /* Though the second half of trampoline page is unused a task could be
> > > - * preempted in the middle of the first half of trampoline and two
> > > - * updates to trampoline would change the code from underneath the
> > > - * preempted task. Hence wait for tasks to voluntarily schedule or go
> > > - * to userspace.
> > > + /* the same trampoline can hold both sleepable and non-sleepable progs.
> > > + * synchronize_rcu_tasks_trace() is needed to make sure all sleepable
> > > + * programs finish executing. It also ensures that the rest of
> > > + * generated tramopline assembly finishes before updating trampoline.
> > > */
> > > -
> > > - synchronize_rcu_tasks();
> > > + synchronize_rcu_tasks_trace();
> >
> > Hi Paul,
> >
> > I've been looking at rcu_trace implementation and I think above change
> > is correct.
> > Could you please double check my understanding?
>
> From an RCU Tasks Trace perspective, it looks good to me!
>
> You have rcu_read_lock_trace() and rcu_read_unlock_trace() protecting
> the readers and synchronize_rcu_trace() waiting for them.
>
> One question given my lack of understanding of BPF: Are there still
> tramoplines for non-sleepable BPF programs? If so, they might still
> need to use synchronize_rcu_tasks() or some such.
The same trampoline can hold both sleepable and non-sleepable progs.
The following is possible:
. trampoline asm starts
. rcu_read_lock + migrate_disable
. non-sleepable prog_A
. rcu_read_unlock + migrate_enable
. trampoline asm
. rcu_read_lock_trace
. sleepable prog_B
. rcu_read_unlock_trace
. trampoline asm
. rcu_read_lock + migrate_disable
. non-sleepable prog_C
. rcu_read_unlock + migrate_enable
. trampoline asm ends
>
> The general principle is "never mix one type of RCU reader with another
> type of RCU updater".
>
> But in this case, one approach is to use synchronize_rcu_mult():
>
> synchronize_rcu_mult(call_rcu_tasks, call_rcu_tasks_trace);
That was my first approach, but I've started looking deeper and looks
like rcu_tasks_trace is stronger than rcu_tasks.
'never mix' is a valid concern, so for future proofing the rcu_mult()
is cleaner, but from safety pov just sync*rcu_tasks_trace() is enough
even when trampoline doesn't hold sleepable progs, right ?
Also timing wise rcu_mult() is obviously faster than doing
one at a time, but how do you sort their speeds:
A: synchronize_rcu_mult(call_rcu_tasks, call_rcu_tasks_trace);
B: synchronize_rcu_tasks();
C: synchronize_rcu_tasks_trace();
> That would wait for both types of readers, and do so concurrently.
> And if there is also a need to wait on rcu_read_lock() and friends,
> you could do this:
>
> synchronize_rcu_mult(call_rcu, call_rcu_tasks, call_rcu_tasks_trace);
I was about to reply that trampoline doesn't need it and there is no such
case yet, but then realized that I can use it in hashtab freeing with:
synchronize_rcu_mult(call_rcu, call_rcu_tasks_trace);
That would be nice optimization.
next prev parent reply other threads:[~2020-06-12 2:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 22:23 [PATCH RFC v3 bpf-next 0/4] bpf: Introduce minimal support for sleepable progs Alexei Starovoitov
2020-06-11 22:23 ` [PATCH RFC v3 bpf-next 1/4] bpf: Introduce sleepable BPF programs Alexei Starovoitov
2020-06-11 22:29 ` Alexei Starovoitov
2020-06-12 0:04 ` Paul E. McKenney
2020-06-12 2:13 ` Alexei Starovoitov [this message]
2020-06-12 3:40 ` Paul E. McKenney
2020-06-11 22:23 ` [PATCH RFC v3 bpf-next 2/4] bpf: Add bpf_copy_from_user() helper Alexei Starovoitov
2020-06-18 22:33 ` Andrii Nakryiko
2020-06-30 0:28 ` Alexei Starovoitov
2020-06-30 18:23 ` Andrii Nakryiko
2020-06-30 18:53 ` Alexei Starovoitov
2020-06-11 22:23 ` [PATCH RFC v3 bpf-next 3/4] libbpf: support sleepable progs Alexei Starovoitov
2020-06-18 22:34 ` Andrii Nakryiko
2020-06-11 22:23 ` [PATCH RFC v3 bpf-next 4/4] selftests/bpf: basic sleepable tests Alexei Starovoitov
2020-06-18 22:43 ` 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=20200612021301.7esez3plqpmjf5wu@ast-mbp.dhcp.thefacebook.com \
--to=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=paulmck@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).