From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: bpf@vger.kernel.org
Cc: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@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@kernel.org>,
"Jamal Hadi Salim" <jhs@mojatatu.com>,
"Vlad Buslov" <vladbu@nvidia.com>,
"Cong Wang" <xiyou.wangcong@gmail.com>,
"Jiri Pirko" <jiri@resnulli.us>,
"David S. Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
"Joe Stringer" <joe@cilium.io>,
"Quentin Monnet" <quentin@isovalent.com>,
"Jesper Dangaard Brouer" <brouer@redhat.com>,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
netdev@vger.kernel.org
Subject: [PATCH RFC bpf-next 4/7] net: sched: add lightweight update path for cls_bpf
Date: Sat, 29 May 2021 01:29:43 +0530 [thread overview]
Message-ID: <20210528195946.2375109-5-memxor@gmail.com> (raw)
In-Reply-To: <20210528195946.2375109-1-memxor@gmail.com>
This is used by BPF_LINK_UPDATE to replace the attach SCHED_CLS bpf prog
effectively changing the classifier implementation for a given filter
owned by a bpf_link.
Note that READ_ONCE suffices in this case as the ordering for loads from
the filter are implicitly provided by the data dependency on BPF prog
pointer.
On the writer side we can just use a relaxed WRITE_ONCE store to make
sure one or the other value is visible to a reader in cls_bpf_classify.
Lifetime is managed using RCU so bpf_prog_put path should wait until
readers are done for old_prog.
All other parties accessing the BPF prog are under RTNL protection, so
need no changes.
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
net/sched/cls_bpf.c | 55 +++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index 57d6dedb389a..459a139bcfbe 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -9,6 +9,7 @@
* (C) 2013 Daniel Borkmann <dborkman@redhat.com>
*/
+#include <linux/atomic.h>
#include <linux/module.h>
#include <linux/types.h>
#include <linux/skbuff.h>
@@ -104,11 +105,11 @@ static int cls_bpf_classify(struct sk_buff *skb, const struct tcf_proto *tp,
/* It is safe to push/pull even if skb_shared() */
__skb_push(skb, skb->mac_len);
bpf_compute_data_pointers(skb);
- filter_res = BPF_PROG_RUN(prog->filter, skb);
+ filter_res = BPF_PROG_RUN(READ_ONCE(prog->filter), skb);
__skb_pull(skb, skb->mac_len);
} else {
bpf_compute_data_pointers(skb);
- filter_res = BPF_PROG_RUN(prog->filter, skb);
+ filter_res = BPF_PROG_RUN(READ_ONCE(prog->filter), skb);
}
if (prog->exts_integrated) {
@@ -775,6 +776,55 @@ static int cls_bpf_link_detach(struct bpf_link *link)
return 0;
}
+static int cls_bpf_link_update(struct bpf_link *link, struct bpf_prog *new_prog,
+ struct bpf_prog *old_prog)
+{
+ struct cls_bpf_link *cls_link;
+ struct cls_bpf_prog cls_prog;
+ struct cls_bpf_prog *prog;
+ int ret;
+
+ rtnl_lock();
+
+ cls_link = container_of(link, struct cls_bpf_link, link);
+ if (!cls_link->prog) {
+ ret = -ENOLINK;
+ goto out;
+ }
+
+ prog = cls_link->prog;
+
+ /* BPF_F_REPLACEing? */
+ if (old_prog && prog->filter != old_prog) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ old_prog = prog->filter;
+
+ if (new_prog == old_prog) {
+ ret = 0;
+ goto out;
+ }
+
+ cls_prog = *prog;
+ cls_prog.filter = new_prog;
+
+ ret = cls_bpf_offload(prog->tp, &cls_prog, prog, NULL);
+ if (ret < 0)
+ goto out;
+
+ WRITE_ONCE(prog->filter, new_prog);
+
+ bpf_prog_inc(new_prog);
+ /* release our reference */
+ bpf_prog_put(old_prog);
+
+out:
+ rtnl_unlock();
+ return ret;
+}
+
static void __bpf_fill_link_info(struct cls_bpf_link *link,
struct bpf_link_info *info)
{
@@ -859,6 +909,7 @@ static const struct bpf_link_ops cls_bpf_link_ops = {
.show_fdinfo = cls_bpf_link_show_fdinfo,
#endif
.fill_link_info = cls_bpf_link_fill_link_info,
+ .update_prog = cls_bpf_link_update,
};
static inline char *cls_bpf_link_name(u32 prog_id, const char *name)
--
2.31.1
next prev parent reply other threads:[~2021-05-28 20:00 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-28 19:59 [PATCH RFC bpf-next 0/7] Add bpf_link based TC-BPF API Kumar Kartikeya Dwivedi
2021-05-28 19:59 ` [PATCH RFC bpf-next 1/7] net: sched: refactor cls_bpf creation code Kumar Kartikeya Dwivedi
2021-05-28 19:59 ` [PATCH RFC bpf-next 2/7] bpf: export bpf_link functions for modules Kumar Kartikeya Dwivedi
2021-05-28 19:59 ` [PATCH RFC bpf-next 3/7] net: sched: add bpf_link API for bpf classifier Kumar Kartikeya Dwivedi
2021-06-02 20:56 ` Andrii Nakryiko
2021-05-28 19:59 ` Kumar Kartikeya Dwivedi [this message]
2021-05-28 19:59 ` [PATCH RFC bpf-next 5/7] tools: bpf.h: sync with kernel sources Kumar Kartikeya Dwivedi
2021-05-28 19:59 ` [PATCH RFC bpf-next 6/7] libbpf: add bpf_link based TC-BPF management API Kumar Kartikeya Dwivedi
2021-06-02 21:03 ` Andrii Nakryiko
2021-05-28 19:59 ` [PATCH RFC bpf-next 7/7] libbpf: add selftest for " Kumar Kartikeya Dwivedi
2021-06-02 21:09 ` [PATCH RFC bpf-next 0/7] Add bpf_link based TC-BPF API Andrii Nakryiko
2021-06-02 21:45 ` Kumar Kartikeya Dwivedi
2021-06-02 23:50 ` Alexei Starovoitov
2021-06-04 6:43 ` Kumar Kartikeya Dwivedi
2021-06-06 23:37 ` Cong Wang
2021-06-07 3:37 ` Kumar Kartikeya Dwivedi
2021-06-07 5:18 ` Cong Wang
2021-06-07 6:07 ` Kumar Kartikeya Dwivedi
2021-06-08 2:00 ` Cong Wang
2021-06-08 7:19 ` Kumar Kartikeya Dwivedi
2021-06-08 15:39 ` Alexei Starovoitov
2021-06-11 2:10 ` Cong Wang
2021-06-11 2:00 ` Cong Wang
2021-06-13 2:53 ` Kumar Kartikeya Dwivedi
2021-06-13 20:27 ` Jamal Hadi Salim
2021-06-13 20:34 ` Kumar Kartikeya Dwivedi
2021-06-13 21:10 ` Jamal Hadi Salim
2021-06-14 13:03 ` Marcelo Ricardo Leitner
2021-06-15 23:07 ` Daniel Borkmann
2021-06-16 14:40 ` Jamal Hadi Salim
2021-06-16 15:32 ` Kumar Kartikeya Dwivedi
2021-06-16 16:00 ` Daniel Borkmann
2021-06-18 11:40 ` Jamal Hadi Salim
2021-06-18 14:38 ` Alexei Starovoitov
2021-06-18 14:50 ` Jamal Hadi Salim
2021-06-18 16:23 ` Alexei Starovoitov
2021-06-18 16:41 ` Jamal Hadi Salim
2021-06-18 22:42 ` Daniel Borkmann
2021-06-21 13:55 ` Jamal Hadi Salim
2021-06-15 4:33 ` Cong Wang
2021-06-15 11:54 ` Toke Høiland-Jørgensen
2021-06-15 23:44 ` Daniel Borkmann
2021-06-16 12:03 ` Toke Høiland-Jørgensen
2021-06-16 15:33 ` Jamal Hadi Salim
2021-06-13 3:08 ` Kumar Kartikeya Dwivedi
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=20210528195946.2375109-5-memxor@gmail.com \
--to=memxor@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=joe@cilium.io \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=quentin@isovalent.com \
--cc=songliubraving@fb.com \
--cc=toke@redhat.com \
--cc=vladbu@nvidia.com \
--cc=xiyou.wangcong@gmail.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 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).