All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf@vger.kernel.org, "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: Re: [PATCH bpf-next v2 4/7] net: sched: add lightweight update path for cls_bpf
Date: Sat, 5 Jun 2021 10:12:04 +0530	[thread overview]
Message-ID: <20210605044204.j3zbrxhdtlf7lziz@apollo> (raw)
In-Reply-To: <20210604175428.f77zeagqavjvdndn@ast-mbp.dhcp.thefacebook.com>

On Fri, Jun 04, 2021 at 11:24:28PM IST, Alexei Starovoitov wrote:
> On Fri, Jun 04, 2021 at 12:01:13PM +0530, Kumar Kartikeya Dwivedi wrote:
> > 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.
>
> Should those be rcu_deref and rcu_assign_pointer ?
> Typically the pointer would be __rcu annotated which would be
> another small change in struct cls_bpf_prog.
> That would make the life time easier to follow?
>

True, I'll make that change.

> > 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;
>
> Other places like cgroup_bpf_replace and bpf_iter_link_replace
> return -EPERM in such case.
>

Ok, will change.

> > +		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
> >
>
> --

--
Kartikeya

  reply	other threads:[~2021-06-05  4:43 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 ` [PATCH bpf-next v2 4/7] net: sched: add lightweight update path for cls_bpf Kumar Kartikeya Dwivedi
2021-06-04 17:54   ` Alexei Starovoitov
2021-06-05  4:42     ` Kumar Kartikeya Dwivedi [this message]
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=20210605044204.j3zbrxhdtlf7lziz@apollo \
    --to=memxor@gmail.com \
    --cc=alexei.starovoitov@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.