All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Blakey <paulb@nvidia.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	John Fastabend <john.fastabend@gmail.com>,
	Saeed Mahameed <saeedm@nvidia.com>, Oz Shlomo <ozsh@nvidia.com>,
	Roi Dayan <roid@nvidia.com>, Vlad Buslov <vladbu@nvidia.com>
Subject: Re: [PATCH net] skbuff: Release nfct refcount on napi stolen or re-used skbs
Date: Thu, 27 May 2021 16:30:57 +0300	[thread overview]
Message-ID: <9b9939-ce24-60ef-cb6d-61732ab21359@nvidia.com> (raw)
In-Reply-To: <81587f89-df10-004e-6c79-34940fe04c16@gmail.com>




On Tue, 25 May 2021, Eric Dumazet wrote:

> 
> 
> On 5/25/21 11:13 AM, Paul Blakey wrote:
> > When multiple SKBs are merged to a new skb under napi GRO,
> > or SKB is re-used by napi, if nfct was set for them in the
> > driver, it will not be released while freeing their stolen
> > head state or on re-use.
> > 
> > Release nfct on napi's stolen or re-used SKBs.
> > 
> > Fixes: 5c6b94604744 ("net/mlx5e: CT: Handle misses after executing CT action")
> > Reviewed-by: Roi Dayan <roid@nvidia.com>
> > Signed-off-by: Paul Blakey <paulb@nvidia.com>
> > ---
> >  net/core/dev.c    | 1 +
> >  net/core/skbuff.c | 1 +
> >  2 files changed, 2 insertions(+)
> > 
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index ef8cf7619baf..a5324ca7dc65 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6243,6 +6243,7 @@ static void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb)
> >  	skb_shinfo(skb)->gso_type = 0;
> >  	skb->truesize = SKB_TRUESIZE(skb_end_offset(skb));
> >  	skb_ext_reset(skb);
> > +	nf_reset_ct(skb);
> >  
> >  	napi->skb = skb;
> >  }
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index 3ad22870298c..6127bab2fe2f 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -939,6 +939,7 @@ void __kfree_skb_defer(struct sk_buff *skb)
> >  
> >  void napi_skb_free_stolen_head(struct sk_buff *skb)
> >  {
> > +	nf_conntrack_put(skb_nfct(skb));
> >  	skb_dst_drop(skb);
> >  	skb_ext_put(skb);
> >  	napi_skb_cache_put(skb);
> > 
> 
> Sadly we are very consistently making GRO slow as hell.
> 
> Why merging SKB with different ct would be allowed ?
> 
> If we accept this patch, then you will likely add another check in gro_list_prepare() ?
> 
> 

Yes, good catch, I'll check if that's even possible in our case.
If so I'm going to add checking diff conntracks on the gro list,
and diff tc chains, both are metadata on the skb.


  reply	other threads:[~2021-05-27 13:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25  9:13 [PATCH net] skbuff: Release nfct refcount on napi stolen or re-used skbs Paul Blakey
2021-05-25 13:45 ` Eric Dumazet
2021-05-27 13:30   ` Paul Blakey [this message]
2021-05-25 14:47 ` kernel test robot
2021-05-25 14:47   ` kernel test robot
2021-05-25 14:50 ` kernel test robot
2021-05-25 14:50   ` kernel test robot

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=9b9939-ce24-60ef-cb6d-61732ab21359@nvidia.com \
    --to=paulb@nvidia.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ozsh@nvidia.com \
    --cc=roid@nvidia.com \
    --cc=saeedm@nvidia.com \
    --cc=vladbu@nvidia.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.