All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: bpf@vger.kernel.org
Cc: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Jamal Hadi Salim" <jhs@mojatatu.com>,
	"Vlad Buslov" <vladbu@nvidia.com>,
	"Cong Wang" <xiyou.wangcong@gmail.com>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	netdev@vger.kernel.org
Subject: [PATCH bpf-next v2 4/7] net: sched: add lightweight update path for cls_bpf
Date: Fri,  4 Jun 2021 12:01:13 +0530	[thread overview]
Message-ID: <20210604063116.234316-5-memxor@gmail.com> (raw)
In-Reply-To: <20210604063116.234316-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.

Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>.
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 bf61ffbb7fd0..f23304685c48 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


  parent reply	other threads:[~2021-06-04  6:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-04  6:31 [PATCH bpf-next v2 0/7] Add bpf_link based TC-BPF API Kumar Kartikeya Dwivedi
2021-06-04  6:31 ` [PATCH bpf-next v2 1/7] net: sched: refactor cls_bpf creation code Kumar Kartikeya Dwivedi
2021-06-04  6:31 ` [PATCH bpf-next v2 2/7] bpf: export bpf_link functions for modules Kumar Kartikeya Dwivedi
2021-06-04  6:31 ` [PATCH bpf-next v2 3/7] net: sched: add bpf_link API for bpf classifier Kumar Kartikeya Dwivedi
2021-06-04 11:32   ` kernel test robot
2021-06-04 11:32     ` kernel test robot
2021-06-05  3:08   ` Yonghong Song
2021-06-05  4:52     ` Kumar Kartikeya Dwivedi
2021-06-07 23:23   ` Andrii Nakryiko
2021-06-04  6:31 ` Kumar Kartikeya Dwivedi [this message]
2021-06-04 17:54   ` [PATCH bpf-next v2 4/7] net: sched: add lightweight update path for cls_bpf Alexei Starovoitov
2021-06-05  4:42     ` Kumar Kartikeya Dwivedi
2021-06-07 23:32   ` Andrii Nakryiko
2021-06-10 14:14     ` Kumar Kartikeya Dwivedi
2021-06-04  6:31 ` [PATCH bpf-next v2 5/7] tools: bpf.h: sync with kernel sources Kumar Kartikeya Dwivedi
2021-06-04  6:31 ` [PATCH bpf-next v2 6/7] libbpf: add bpf_link based TC-BPF management API Kumar Kartikeya Dwivedi
2021-06-04 18:01   ` Alexei Starovoitov
2021-06-05  4:51     ` Kumar Kartikeya Dwivedi
2021-06-07 23:37       ` Andrii Nakryiko
2021-06-05 17:09   ` Yonghong Song
2021-06-07 23:41   ` Andrii Nakryiko
2021-06-04  6:31 ` [PATCH bpf-next v2 7/7] libbpf: add selftest for " Kumar Kartikeya Dwivedi
2021-06-05 17:26   ` Yonghong Song
2021-06-07 23:57   ` Andrii Nakryiko
2022-06-10  0:24 ` [PATCH bpf-next v2 0/7] Add bpf_link based TC-BPF API Joanne Koong
2022-06-10 12:58   ` Kumar Kartikeya Dwivedi
2022-06-10 17:23     ` Joanne Koong
2022-06-10 19:07       ` Joanne Koong
2022-06-10 19:34         ` Kumar Kartikeya Dwivedi
2022-06-10 20:04           ` Daniel Borkmann
2022-06-10 22:01             ` Joanne Koong
2022-06-10 20:16           ` Toke Høiland-Jørgensen
2022-06-10 20:35             ` Daniel Borkmann
2022-06-10 20:41               ` Toke Høiland-Jørgensen
2022-06-10 21:52                 ` Alexei Starovoitov
2022-06-10 22:02                   ` Daniel Borkmann
2022-06-11 10:54                     ` Toke Høiland-Jørgensen

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=20210604063116.234316-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=jhs@mojatatu.com \
    --cc=netdev@vger.kernel.org \
    --cc=toke@redhat.com \
    --cc=vladbu@nvidia.com \
    --cc=xiyou.wangcong@gmail.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.