* [RFC nf-next 0/2] netfilter: bpf: support prog update @ 2023-12-13 11:45 D. Wythe 2023-12-13 11:45 ` [RFC nf-next 1/2] " D. Wythe 2023-12-13 11:45 ` [RFC nf-next 2/2] selftests/bpf: Add netfilter link prog update test D. Wythe 0 siblings, 2 replies; 12+ messages in thread From: D. Wythe @ 2023-12-13 11:45 UTC (permalink / raw) To: pablo, kadlec, fw Cc: bpf, linux-kernel, netdev, coreteam, netfilter-devel, davem, edumazet, kuba, pabeni, ast, D. Wythe From: "D. Wythe" <alibuda@linux.alibaba.com> This patches attempt to support updating of progs with bpf netfilter link, introducing a new RCU-protected context to access the prog, and adding a corresponding test case. D. Wythe (2): netfilter: bpf: support prog update selftests/bpf: Add netfilter link prog update test net/netfilter/nf_bpf_link.c | 124 ++++++++++++++++++--- .../bpf/prog_tests/netfilter_link_update_prog.c | 83 ++++++++++++++ .../bpf/progs/test_netfilter_link_update_prog.c | 24 ++++ 3 files changed, 218 insertions(+), 13 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/netfilter_link_update_prog.c create mode 100644 tools/testing/selftests/bpf/progs/test_netfilter_link_update_prog.c -- 1.8.3.1 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [RFC nf-next 1/2] netfilter: bpf: support prog update 2023-12-13 11:45 [RFC nf-next 0/2] netfilter: bpf: support prog update D. Wythe @ 2023-12-13 11:45 ` D. Wythe 2023-12-13 22:24 ` Florian Westphal 2023-12-13 11:45 ` [RFC nf-next 2/2] selftests/bpf: Add netfilter link prog update test D. Wythe 1 sibling, 1 reply; 12+ messages in thread From: D. Wythe @ 2023-12-13 11:45 UTC (permalink / raw) To: pablo, kadlec, fw Cc: bpf, linux-kernel, netdev, coreteam, netfilter-devel, davem, edumazet, kuba, pabeni, ast, D. Wythe From: "D. Wythe" <alibuda@linux.alibaba.com> To support the prog update, we need to ensure that the prog seen within the hook is always valid. Considering that hooks are always protected by rcu_read_lock(), which provide us the ability to use a new RCU-protected context to access the prog. Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> --- net/netfilter/nf_bpf_link.c | 124 +++++++++++++++++++++++++++++++++++++++----- 1 file changed, 111 insertions(+), 13 deletions(-) diff --git a/net/netfilter/nf_bpf_link.c b/net/netfilter/nf_bpf_link.c index e502ec0..918c470 100644 --- a/net/netfilter/nf_bpf_link.c +++ b/net/netfilter/nf_bpf_link.c @@ -8,17 +8,11 @@ #include <net/netfilter/nf_bpf_link.h> #include <uapi/linux/netfilter_ipv4.h> -static unsigned int nf_hook_run_bpf(void *bpf_prog, struct sk_buff *skb, - const struct nf_hook_state *s) +struct bpf_nf_hook_ctx { - const struct bpf_prog *prog = bpf_prog; - struct bpf_nf_ctx ctx = { - .state = s, - .skb = skb, - }; - - return bpf_prog_run(prog, &ctx); -} + struct bpf_prog *prog; + struct rcu_head rcu; +}; struct bpf_nf_link { struct bpf_link link; @@ -26,8 +20,59 @@ struct bpf_nf_link { struct net *net; u32 dead; const struct nf_defrag_hook *defrag_hook; + /* protect link update in parallel */ + struct mutex update_lock; + struct bpf_nf_hook_ctx __rcu *hook_ctx; }; +static struct bpf_nf_hook_ctx * +bpf_nf_hook_ctx_from_prog(struct bpf_prog *prog, gfp_t flags) +{ + struct bpf_nf_hook_ctx *hook_ctx; + + hook_ctx = kmalloc(sizeof(*hook_ctx), flags); + if (hook_ctx) { + hook_ctx->prog = prog; + bpf_prog_inc(prog); + } + return hook_ctx; +} + +static void bpf_nf_hook_ctx_free(struct bpf_nf_hook_ctx *hook_ctx) +{ + if (!hook_ctx) + return; + if (hook_ctx->prog) + bpf_prog_put(hook_ctx->prog); + kfree(hook_ctx); +} + +static void __bpf_nf_hook_ctx_free_rcu(struct rcu_head *head) +{ + struct bpf_nf_hook_ctx *hook_ctx = container_of(head, struct bpf_nf_hook_ctx, rcu); + + bpf_nf_hook_ctx_free(hook_ctx); +} + +static void bpf_nf_hook_ctx_free_rcu(struct bpf_nf_hook_ctx *hook_ctx) +{ + call_rcu(&hook_ctx->rcu, __bpf_nf_hook_ctx_free_rcu); +} + +static unsigned int nf_hook_run_bpf(void *bpf_link, struct sk_buff *skb, + const struct nf_hook_state *s) +{ + const struct bpf_nf_link *link = bpf_link; + struct bpf_nf_hook_ctx *hook_ctx; + struct bpf_nf_ctx ctx = { + .state = s, + .skb = skb, + }; + + hook_ctx = rcu_dereference(link->hook_ctx); + return bpf_prog_run(hook_ctx->prog, &ctx); +} + #if IS_ENABLED(CONFIG_NF_DEFRAG_IPV4) || IS_ENABLED(CONFIG_NF_DEFRAG_IPV6) static const struct nf_defrag_hook * get_proto_defrag_hook(struct bpf_nf_link *link, @@ -120,6 +165,10 @@ static void bpf_nf_link_release(struct bpf_link *link) if (!cmpxchg(&nf_link->dead, 0, 1)) { nf_unregister_net_hook(nf_link->net, &nf_link->hook_ops); bpf_nf_disable_defrag(nf_link); + /* Wait for outstanding hook to complete before the + * link gets released. + */ + synchronize_rcu(); } } @@ -127,6 +176,7 @@ static void bpf_nf_link_dealloc(struct bpf_link *link) { struct bpf_nf_link *nf_link = container_of(link, struct bpf_nf_link, link); + bpf_nf_hook_ctx_free(nf_link->hook_ctx); kfree(nf_link); } @@ -162,7 +212,42 @@ static int bpf_nf_link_fill_link_info(const struct bpf_link *link, static int bpf_nf_link_update(struct bpf_link *link, struct bpf_prog *new_prog, struct bpf_prog *old_prog) { - return -EOPNOTSUPP; + struct bpf_nf_link *nf_link = container_of(link, struct bpf_nf_link, link); + struct bpf_nf_hook_ctx *hook_ctx; + int err = 0; + + mutex_lock(&nf_link->update_lock); + + /* target old_prog mismatch */ + if (old_prog && link->prog != old_prog) { + err = -EPERM; + goto out; + } + + old_prog = link->prog; + if (old_prog == new_prog) { + /* don't need update */ + bpf_prog_put(new_prog); + goto out; + } + + hook_ctx = bpf_nf_hook_ctx_from_prog(new_prog, GFP_USER); + if (!hook_ctx) { + err = -ENOMEM; + goto out; + } + + /* replace and get the old one */ + hook_ctx = rcu_replace_pointer(nf_link->hook_ctx, hook_ctx, + lockdep_is_held(&nf_link->update_lock)); + /* free old hook_ctx */ + bpf_nf_hook_ctx_free_rcu(hook_ctx); + + old_prog = xchg(&link->prog, new_prog); + bpf_prog_put(old_prog); +out: + mutex_unlock(&nf_link->update_lock); + return err; } static const struct bpf_link_ops bpf_nf_link_lops = { @@ -222,11 +307,22 @@ int bpf_nf_link_attach(const union bpf_attr *attr, struct bpf_prog *prog) if (!link) return -ENOMEM; + link->hook_ctx = bpf_nf_hook_ctx_from_prog(prog, GFP_USER); + if (!link->hook_ctx) { + kfree(link); + return -ENOMEM; + } + bpf_link_init(&link->link, BPF_LINK_TYPE_NETFILTER, &bpf_nf_link_lops, prog); link->hook_ops.hook = nf_hook_run_bpf; link->hook_ops.hook_ops_type = NF_HOOK_OP_BPF; - link->hook_ops.priv = prog; + + /* bpf_nf_link_release() ensures that after its execution, there will be + * no ongoing or upcoming execution of nf_hook_run_bpf() within any context. + * Therefore, within nf_hook_run_bpf(), the link remains valid at all times." + */ + link->hook_ops.priv = link; link->hook_ops.pf = attr->link_create.netfilter.pf; link->hook_ops.priority = attr->link_create.netfilter.priority; @@ -236,9 +332,11 @@ int bpf_nf_link_attach(const union bpf_attr *attr, struct bpf_prog *prog) link->dead = false; link->defrag_hook = NULL; + mutex_init(&link->update_lock); + err = bpf_link_prime(&link->link, &link_primer); if (err) { - kfree(link); + bpf_nf_link_dealloc(&link->link); return err; } -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [RFC nf-next 1/2] netfilter: bpf: support prog update 2023-12-13 11:45 ` [RFC nf-next 1/2] " D. Wythe @ 2023-12-13 22:24 ` Florian Westphal 2023-12-14 3:25 ` Alexei Starovoitov 2023-12-14 5:31 ` D. Wythe 0 siblings, 2 replies; 12+ messages in thread From: Florian Westphal @ 2023-12-13 22:24 UTC (permalink / raw) To: D. Wythe Cc: pablo, kadlec, fw, bpf, linux-kernel, netdev, coreteam, netfilter-devel, davem, edumazet, kuba, pabeni, ast D. Wythe <alibuda@linux.alibaba.com> wrote: > From: "D. Wythe" <alibuda@linux.alibaba.com> > > To support the prog update, we need to ensure that the prog seen > within the hook is always valid. Considering that hooks are always > protected by rcu_read_lock(), which provide us the ability to use a > new RCU-protected context to access the prog. > > Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> > --- > net/netfilter/nf_bpf_link.c | 124 +++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 111 insertions(+), 13 deletions(-) > > diff --git a/net/netfilter/nf_bpf_link.c b/net/netfilter/nf_bpf_link.c > index e502ec0..918c470 100644 > --- a/net/netfilter/nf_bpf_link.c > +++ b/net/netfilter/nf_bpf_link.c > @@ -8,17 +8,11 @@ > #include <net/netfilter/nf_bpf_link.h> > #include <uapi/linux/netfilter_ipv4.h> > > -static unsigned int nf_hook_run_bpf(void *bpf_prog, struct sk_buff *skb, > - const struct nf_hook_state *s) > +struct bpf_nf_hook_ctx > { > - const struct bpf_prog *prog = bpf_prog; > - struct bpf_nf_ctx ctx = { > - .state = s, > - .skb = skb, > - }; > - > - return bpf_prog_run(prog, &ctx); > -} > + struct bpf_prog *prog; > + struct rcu_head rcu; > +}; I don't understand the need for this structure. AFAICS bpf_prog_put() will always release the program via call_rcu()? If it doesn't, we are probably already in trouble as-is without this patch, I don't think anything that prevents us from ending up calling already released bpf prog, or releasing it while another cpu is still running it if bpf_prog_put releases the actual underlying prog instantly. A BPF expert could confirm bpf-prog-put-is-call-rcu. > struct bpf_nf_link { > struct bpf_link link; > @@ -26,8 +20,59 @@ struct bpf_nf_link { > struct net *net; > u32 dead; > const struct nf_defrag_hook *defrag_hook; > + /* protect link update in parallel */ > + struct mutex update_lock; > + struct bpf_nf_hook_ctx __rcu *hook_ctx; What kind of replacements-per-second rate are you aiming for? I think static DEFINE_MUTEX(bpf_nf_mutex); is enough. Then bpf_nf_link gains struct bpf_prog __rcu *prog and possibly a trailing struct rcu_head, see below. > +static void bpf_nf_hook_ctx_free_rcu(struct bpf_nf_hook_ctx *hook_ctx) > +{ > + call_rcu(&hook_ctx->rcu, __bpf_nf_hook_ctx_free_rcu); > +} Don't understand the need for call_rcu either, see below. > +static unsigned int nf_hook_run_bpf(void *bpf_link, struct sk_buff *skb, > + const struct nf_hook_state *s) > +{ > + const struct bpf_nf_link *link = bpf_link; > + struct bpf_nf_hook_ctx *hook_ctx; > + struct bpf_nf_ctx ctx = { > + .state = s, > + .skb = skb, > + }; > + > + hook_ctx = rcu_dereference(link->hook_ctx); This could then just rcu_deref link->prog. > + return bpf_prog_run(hook_ctx->prog, &ctx); > +} > + > #if IS_ENABLED(CONFIG_NF_DEFRAG_IPV4) || IS_ENABLED(CONFIG_NF_DEFRAG_IPV6) > static const struct nf_defrag_hook * > get_proto_defrag_hook(struct bpf_nf_link *link, > @@ -120,6 +165,10 @@ static void bpf_nf_link_release(struct bpf_link *link) > if (!cmpxchg(&nf_link->dead, 0, 1)) { > nf_unregister_net_hook(nf_link->net, &nf_link->hook_ops); > bpf_nf_disable_defrag(nf_link); > + /* Wait for outstanding hook to complete before the > + * link gets released. > + */ > + synchronize_rcu(); > } Could you convert bpf_nf_link_dealloc to release via kfree_rcu instead? > @@ -162,7 +212,42 @@ static int bpf_nf_link_fill_link_info(const struct bpf_link *link, > static int bpf_nf_link_update(struct bpf_link *link, struct bpf_prog *new_prog, > struct bpf_prog *old_prog) > { > - return -EOPNOTSUPP; > + struct bpf_nf_link *nf_link = container_of(link, struct bpf_nf_link, link); > + struct bpf_nf_hook_ctx *hook_ctx; > + int err = 0; > + > + mutex_lock(&nf_link->update_lock); > + I think you need to check link->dead here too. > + /* bpf_nf_link_release() ensures that after its execution, there will be > + * no ongoing or upcoming execution of nf_hook_run_bpf() within any context. > + * Therefore, within nf_hook_run_bpf(), the link remains valid at all times." > + */ > + link->hook_ops.priv = link; ATM we only need to make sure the bpf prog itself stays alive until after all concurrent rcu critical sections have completed. After this change, struct bpf_link gets passed instead, so we need to keep that alive too. Which works with synchronize_rcu, sure, but that seems a bit overkill here. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC nf-next 1/2] netfilter: bpf: support prog update 2023-12-13 22:24 ` Florian Westphal @ 2023-12-14 3:25 ` Alexei Starovoitov 2023-12-14 5:31 ` D. Wythe 1 sibling, 0 replies; 12+ messages in thread From: Alexei Starovoitov @ 2023-12-14 3:25 UTC (permalink / raw) To: Florian Westphal Cc: D. Wythe, Pablo Neira Ayuso, Jozsef Kadlecsik, bpf, LKML, Network Development, coreteam, netfilter-devel, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexei Starovoitov On Wed, Dec 13, 2023 at 2:24 PM Florian Westphal <fw@strlen.de> wrote: > > D. Wythe <alibuda@linux.alibaba.com> wrote: > > From: "D. Wythe" <alibuda@linux.alibaba.com> > > > > To support the prog update, we need to ensure that the prog seen > > within the hook is always valid. Considering that hooks are always > > protected by rcu_read_lock(), which provide us the ability to use a > > new RCU-protected context to access the prog. > > > > Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> > > --- > > net/netfilter/nf_bpf_link.c | 124 +++++++++++++++++++++++++++++++++++++++----- > > 1 file changed, 111 insertions(+), 13 deletions(-) > > > > diff --git a/net/netfilter/nf_bpf_link.c b/net/netfilter/nf_bpf_link.c > > index e502ec0..918c470 100644 > > --- a/net/netfilter/nf_bpf_link.c > > +++ b/net/netfilter/nf_bpf_link.c > > @@ -8,17 +8,11 @@ > > #include <net/netfilter/nf_bpf_link.h> > > #include <uapi/linux/netfilter_ipv4.h> > > > > -static unsigned int nf_hook_run_bpf(void *bpf_prog, struct sk_buff *skb, > > - const struct nf_hook_state *s) > > +struct bpf_nf_hook_ctx > > { > > - const struct bpf_prog *prog = bpf_prog; > > - struct bpf_nf_ctx ctx = { > > - .state = s, > > - .skb = skb, > > - }; > > - > > - return bpf_prog_run(prog, &ctx); > > -} > > + struct bpf_prog *prog; > > + struct rcu_head rcu; > > +}; > > I don't understand the need for this structure. AFAICS bpf_prog_put() > will always release the program via call_rcu()? > > If it doesn't, we are probably already in trouble as-is without this > patch, I don't think anything that prevents us from ending up calling already > released bpf prog, or releasing it while another cpu is still running it > if bpf_prog_put releases the actual underlying prog instantly. > > A BPF expert could confirm bpf-prog-put-is-call-rcu. +1 These patches look unnecessary. It seems that they accidently fix something else. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC nf-next 1/2] netfilter: bpf: support prog update 2023-12-13 22:24 ` Florian Westphal 2023-12-14 3:25 ` Alexei Starovoitov @ 2023-12-14 5:31 ` D. Wythe 2023-12-14 5:50 ` Alexei Starovoitov 1 sibling, 1 reply; 12+ messages in thread From: D. Wythe @ 2023-12-14 5:31 UTC (permalink / raw) To: Florian Westphal Cc: pablo, kadlec, bpf, linux-kernel, netdev, coreteam, netfilter-devel, davem, edumazet, kuba, pabeni, ast On 12/14/23 6:24 AM, Florian Westphal wrote: > D. Wythe <alibuda@linux.alibaba.com> wrote: >> From: "D. Wythe" <alibuda@linux.alibaba.com> >> >> To support the prog update, we need to ensure that the prog seen >> within the hook is always valid. Considering that hooks are always >> protected by rcu_read_lock(), which provide us the ability to use a >> new RCU-protected context to access the prog. >> >> Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> >> --- >> net/netfilter/nf_bpf_link.c | 124 +++++++++++++++++++++++++++++++++++++++----- >> 1 file changed, 111 insertions(+), 13 deletions(-) >> >> diff --git a/net/netfilter/nf_bpf_link.c b/net/netfilter/nf_bpf_link.c >> index e502ec0..918c470 100644 >> --- a/net/netfilter/nf_bpf_link.c >> +++ b/net/netfilter/nf_bpf_link.c >> @@ -8,17 +8,11 @@ >> #include <net/netfilter/nf_bpf_link.h> >> #include <uapi/linux/netfilter_ipv4.h> >> >> -static unsigned int nf_hook_run_bpf(void *bpf_prog, struct sk_buff *skb, >> - const struct nf_hook_state *s) >> +struct bpf_nf_hook_ctx >> { >> - const struct bpf_prog *prog = bpf_prog; >> - struct bpf_nf_ctx ctx = { >> - .state = s, >> - .skb = skb, >> - }; >> - >> - return bpf_prog_run(prog, &ctx); >> -} >> + struct bpf_prog *prog; >> + struct rcu_head rcu; >> +}; > I don't understand the need for this structure. AFAICS bpf_prog_put() > will always release the program via call_rcu()? > > If it doesn't, we are probably already in trouble as-is without this > patch, I don't think anything that prevents us from ending up calling already > released bpf prog, or releasing it while another cpu is still running it > if bpf_prog_put releases the actual underlying prog instantly. > > A BPF expert could confirm bpf-prog-put-is-call-rcu. Hi Florian, I must admit that I did not realize that bpf_prog is released under RCU ... >> struct bpf_nf_link { >> struct bpf_link link; >> @@ -26,8 +20,59 @@ struct bpf_nf_link { >> struct net *net; >> u32 dead; >> const struct nf_defrag_hook *defrag_hook; >> + /* protect link update in parallel */ >> + struct mutex update_lock; >> + struct bpf_nf_hook_ctx __rcu *hook_ctx; > What kind of replacements-per-second rate are you aiming for? > I think > > static DEFINE_MUTEX(bpf_nf_mutex); > > is enough. I'm okay with that. > > Then bpf_nf_link gains > > struct bpf_prog __rcu *prog > > and possibly a trailing struct rcu_head, see below. Yes, that's what we need. >> +static void bpf_nf_hook_ctx_free_rcu(struct bpf_nf_hook_ctx *hook_ctx) >> +{ >> + call_rcu(&hook_ctx->rcu, __bpf_nf_hook_ctx_free_rcu); >> +} > Don't understand the need for call_rcu either, see below. > >> +static unsigned int nf_hook_run_bpf(void *bpf_link, struct sk_buff *skb, >> + const struct nf_hook_state *s) >> +{ >> + const struct bpf_nf_link *link = bpf_link; >> + struct bpf_nf_hook_ctx *hook_ctx; >> + struct bpf_nf_ctx ctx = { >> + .state = s, >> + .skb = skb, >> + }; >> + >> + hook_ctx = rcu_dereference(link->hook_ctx); > This could then just rcu_deref link->prog. > >> + return bpf_prog_run(hook_ctx->prog, &ctx); >> +} >> + >> #if IS_ENABLED(CONFIG_NF_DEFRAG_IPV4) || IS_ENABLED(CONFIG_NF_DEFRAG_IPV6) >> static const struct nf_defrag_hook * >> get_proto_defrag_hook(struct bpf_nf_link *link, >> @@ -120,6 +165,10 @@ static void bpf_nf_link_release(struct bpf_link *link) >> if (!cmpxchg(&nf_link->dead, 0, 1)) { >> nf_unregister_net_hook(nf_link->net, &nf_link->hook_ops); >> bpf_nf_disable_defrag(nf_link); >> + /* Wait for outstanding hook to complete before the >> + * link gets released. >> + */ >> + synchronize_rcu(); >> } > Could you convert bpf_nf_link_dealloc to release via kfree_rcu instead? > Got it. >> @@ -162,7 +212,42 @@ static int bpf_nf_link_fill_link_info(const struct bpf_link *link, >> static int bpf_nf_link_update(struct bpf_link *link, struct bpf_prog *new_prog, >> struct bpf_prog *old_prog) >> { >> - return -EOPNOTSUPP; >> + struct bpf_nf_link *nf_link = container_of(link, struct bpf_nf_link, link); >> + struct bpf_nf_hook_ctx *hook_ctx; >> + int err = 0; >> + >> + mutex_lock(&nf_link->update_lock); >> + > I think you need to check link->dead here too. Got that. > >> + /* bpf_nf_link_release() ensures that after its execution, there will be >> + * no ongoing or upcoming execution of nf_hook_run_bpf() within any context. >> + * Therefore, within nf_hook_run_bpf(), the link remains valid at all times." >> + */ >> + link->hook_ops.priv = link; > ATM we only need to make sure the bpf prog itself stays alive until after > all concurrent rcu critical sections have completed. > > After this change, struct bpf_link gets passed instead, so we need to > keep that alive too. > > Which works with synchronize_rcu, sure, but that seems a bit overkill here. Got it! Thank you very much for your suggestion. I will address those issues you mentioned in the next version. Best wishes, D. Wythe ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC nf-next 1/2] netfilter: bpf: support prog update 2023-12-14 5:31 ` D. Wythe @ 2023-12-14 5:50 ` Alexei Starovoitov 2023-12-14 8:56 ` D. Wythe 0 siblings, 1 reply; 12+ messages in thread From: Alexei Starovoitov @ 2023-12-14 5:50 UTC (permalink / raw) To: D. Wythe Cc: Florian Westphal, Pablo Neira Ayuso, Jozsef Kadlecsik, bpf, LKML, Network Development, coreteam, netfilter-devel, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexei Starovoitov On Wed, Dec 13, 2023 at 9:31 PM D. Wythe <alibuda@linux.alibaba.com> wrote: > > I will address those issues you mentioned in the next version. Don't. There is no need for the next version. None of these changes are necessary. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC nf-next 1/2] netfilter: bpf: support prog update 2023-12-14 5:50 ` Alexei Starovoitov @ 2023-12-14 8:56 ` D. Wythe 2023-12-14 13:37 ` Alexei Starovoitov 0 siblings, 1 reply; 12+ messages in thread From: D. Wythe @ 2023-12-14 8:56 UTC (permalink / raw) To: Alexei Starovoitov Cc: Florian Westphal, Pablo Neira Ayuso, Jozsef Kadlecsik, bpf, LKML, Network Development, coreteam, netfilter-devel, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexei Starovoitov On 12/14/23 1:50 PM, Alexei Starovoitov wrote: > On Wed, Dec 13, 2023 at 9:31 PM D. Wythe <alibuda@linux.alibaba.com> wrote: >> I will address those issues you mentioned in the next version. > Don't. There is no need for the next version. > None of these changes are necessary. Can I know the reason ? Updating prog for active link is kind of important feature for real application.. Best wishes, D. Wythe ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC nf-next 1/2] netfilter: bpf: support prog update 2023-12-14 8:56 ` D. Wythe @ 2023-12-14 13:37 ` Alexei Starovoitov 2023-12-14 15:56 ` D. Wythe 0 siblings, 1 reply; 12+ messages in thread From: Alexei Starovoitov @ 2023-12-14 13:37 UTC (permalink / raw) To: D. Wythe Cc: Florian Westphal, Pablo Neira Ayuso, Jozsef Kadlecsik, bpf, LKML, Network Development, coreteam, netfilter-devel, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexei Starovoitov On Thu, Dec 14, 2023 at 12:57 AM D. Wythe <alibuda@linux.alibaba.com> wrote: > > > > On 12/14/23 1:50 PM, Alexei Starovoitov wrote: > > On Wed, Dec 13, 2023 at 9:31 PM D. Wythe <alibuda@linux.alibaba.com> wrote: > >> I will address those issues you mentioned in the next version. > > Don't. There is no need for the next version. > > None of these changes are necessary. > > Can I know the reason ? Updating prog for active link is kind of > important feature > for real application.. yes. it's and it's working as expected. Do you see an issue? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC nf-next 1/2] netfilter: bpf: support prog update 2023-12-14 13:37 ` Alexei Starovoitov @ 2023-12-14 15:56 ` D. Wythe 2023-12-14 16:02 ` Alexei Starovoitov 0 siblings, 1 reply; 12+ messages in thread From: D. Wythe @ 2023-12-14 15:56 UTC (permalink / raw) To: Alexei Starovoitov Cc: Florian Westphal, Pablo Neira Ayuso, Jozsef Kadlecsik, bpf, LKML, Network Development, coreteam, netfilter-devel, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexei Starovoitov On 12/14/23 9:37 PM, Alexei Starovoitov wrote: > yes. it's and it's working as expected. Do you see an issue? Hi Alexei, I see the issue here is that bpf_nf_link has not yet implemented prog_update, which just simply returned -EOPNOTSUPP right now. Do you mean that it is already implemented in the latest tree or the not-supported was expected? Thanks, D. Wythe ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC nf-next 1/2] netfilter: bpf: support prog update 2023-12-14 15:56 ` D. Wythe @ 2023-12-14 16:02 ` Alexei Starovoitov 2023-12-14 16:10 ` D. Wythe 0 siblings, 1 reply; 12+ messages in thread From: Alexei Starovoitov @ 2023-12-14 16:02 UTC (permalink / raw) To: D. Wythe Cc: Florian Westphal, Pablo Neira Ayuso, Jozsef Kadlecsik, bpf, LKML, Network Development, coreteam, netfilter-devel, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexei Starovoitov On Thu, Dec 14, 2023 at 7:56 AM D. Wythe <alibuda@linux.alibaba.com> wrote: > > > > On 12/14/23 9:37 PM, Alexei Starovoitov wrote: > > yes. it's and it's working as expected. Do you see an issue? > > Hi Alexei, > > I see the issue here is that bpf_nf_link has not yet implemented > prog_update, > which just simply returned -EOPNOTSUPP right now. I see. The commit log didn't make it clear. Yes. That would be good to support. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC nf-next 1/2] netfilter: bpf: support prog update 2023-12-14 16:02 ` Alexei Starovoitov @ 2023-12-14 16:10 ` D. Wythe 0 siblings, 0 replies; 12+ messages in thread From: D. Wythe @ 2023-12-14 16:10 UTC (permalink / raw) To: Alexei Starovoitov Cc: Florian Westphal, Pablo Neira Ayuso, Jozsef Kadlecsik, bpf, LKML, Network Development, coreteam, netfilter-devel, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexei Starovoitov On 12/15/23 12:02 AM, Alexei Starovoitov wrote: > I see. The commit log didn't make it clear. > Yes. That would be good to support. That's my bad. I will make the commit log more clear in the next version. In any case, thanks very much for your feedback. Besh wishes, D. Wythe ^ permalink raw reply [flat|nested] 12+ messages in thread
* [RFC nf-next 2/2] selftests/bpf: Add netfilter link prog update test 2023-12-13 11:45 [RFC nf-next 0/2] netfilter: bpf: support prog update D. Wythe 2023-12-13 11:45 ` [RFC nf-next 1/2] " D. Wythe @ 2023-12-13 11:45 ` D. Wythe 1 sibling, 0 replies; 12+ messages in thread From: D. Wythe @ 2023-12-13 11:45 UTC (permalink / raw) To: pablo, kadlec, fw Cc: bpf, linux-kernel, netdev, coreteam, netfilter-devel, davem, edumazet, kuba, pabeni, ast, D. Wythe From: "D. Wythe" <alibuda@linux.alibaba.com> Update prog for active link and verify whether the prog has been successfully replaced. Expected output: ./test_progs -t netfilter_link_update_prog Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> --- .../bpf/prog_tests/netfilter_link_update_prog.c | 83 ++++++++++++++++++++++ .../bpf/progs/test_netfilter_link_update_prog.c | 24 +++++++ 2 files changed, 107 insertions(+) create mode 100644 tools/testing/selftests/bpf/prog_tests/netfilter_link_update_prog.c create mode 100644 tools/testing/selftests/bpf/progs/test_netfilter_link_update_prog.c diff --git a/tools/testing/selftests/bpf/prog_tests/netfilter_link_update_prog.c b/tools/testing/selftests/bpf/prog_tests/netfilter_link_update_prog.c new file mode 100644 index 00000000..d23b544 --- /dev/null +++ b/tools/testing/selftests/bpf/prog_tests/netfilter_link_update_prog.c @@ -0,0 +1,83 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +#include <test_progs.h> +#include <linux/netfilter.h> +#include <network_helpers.h> +#include "test_netfilter_link_update_prog.skel.h" + +#define SERVER_ADDR "127.0.0.1" +#define SERVER_PORT 12345 + +static const char dummy_message[] = "A dummy message"; + +static int send_dummy(int client_fd) +{ + struct sockaddr_storage saddr; + struct sockaddr *saddr_p; + socklen_t saddr_len; + int err; + + saddr_p = (struct sockaddr *)&saddr; + err = make_sockaddr(AF_INET, SERVER_ADDR, SERVER_PORT, &saddr, &saddr_len); + if (!ASSERT_OK(err, "make_sockaddr")) + return -1; + + err = sendto(client_fd, dummy_message, sizeof(dummy_message) - 1, 0, saddr_p, saddr_len); + if (!ASSERT_GE(err, 0, "sendto")) + return -1; + + return 0; +} + +void test_netfilter_link_update_prog(void) +{ + LIBBPF_OPTS(bpf_netfilter_opts, opts, + .pf = NFPROTO_IPV4, + .hooknum = NF_INET_LOCAL_OUT, + .priority = 100); + struct test_netfilter_link_update_prog *skel; + struct bpf_program *prog; + int server_fd, client_fd; + int err; + + skel = test_netfilter_link_update_prog__open_and_load(); + if (!ASSERT_OK_PTR(skel, "test_netfilter_link_update_prog__open_and_load")) + goto out; + + prog = skel->progs.nf_link_prog; + + if (!ASSERT_OK_PTR(prog, "load program")) + goto out; + + skel->links.nf_link_prog = bpf_program__attach_netfilter(prog, &opts); + if (!ASSERT_OK_PTR(skel->links.nf_link_prog, "attach netfilter program")) + goto out; + + server_fd = start_server(AF_INET, SOCK_DGRAM, SERVER_ADDR, SERVER_PORT, 0); + if (!ASSERT_GE(server_fd, 0, "start_server")) + goto out; + + client_fd = connect_to_fd(server_fd, 0); + if (!ASSERT_GE(client_fd, 0, "connect_to_fd")) + goto out; + + send_dummy(client_fd); + + ASSERT_EQ(skel->bss->counter, 0, "counter should be zero"); + + err = bpf_link__update_program(skel->links.nf_link_prog, skel->progs.nf_link_prog_new); + if (!ASSERT_OK(err, "bpf_link__update_program")) + goto out; + + send_dummy(client_fd); + ASSERT_GE(skel->bss->counter, 0, "counter should be greater than zero"); +out: + if (client_fd > 0) + close(client_fd); + if (server_fd > 0) + close(server_fd); + + test_netfilter_link_update_prog__destroy(skel); +} + + diff --git a/tools/testing/selftests/bpf/progs/test_netfilter_link_update_prog.c b/tools/testing/selftests/bpf/progs/test_netfilter_link_update_prog.c new file mode 100644 index 00000000..42ae332 --- /dev/null +++ b/tools/testing/selftests/bpf/progs/test_netfilter_link_update_prog.c @@ -0,0 +1,24 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +#include "vmlinux.h" +#include <bpf/bpf_helpers.h> + +#define NF_ACCEPT 1 + +SEC("netfilter") +int nf_link_prog(struct bpf_nf_ctx *ctx) +{ + return NF_ACCEPT; +} + +u64 counter = 0; + +SEC("netfilter") +int nf_link_prog_new(struct bpf_nf_ctx *ctx) +{ + counter++; + return NF_ACCEPT; +} + +char _license[] SEC("license") = "GPL"; + -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-12-14 16:10 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-12-13 11:45 [RFC nf-next 0/2] netfilter: bpf: support prog update D. Wythe 2023-12-13 11:45 ` [RFC nf-next 1/2] " D. Wythe 2023-12-13 22:24 ` Florian Westphal 2023-12-14 3:25 ` Alexei Starovoitov 2023-12-14 5:31 ` D. Wythe 2023-12-14 5:50 ` Alexei Starovoitov 2023-12-14 8:56 ` D. Wythe 2023-12-14 13:37 ` Alexei Starovoitov 2023-12-14 15:56 ` D. Wythe 2023-12-14 16:02 ` Alexei Starovoitov 2023-12-14 16:10 ` D. Wythe 2023-12-13 11:45 ` [RFC nf-next 2/2] selftests/bpf: Add netfilter link prog update test D. Wythe
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).