All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jianbo Liu <jianbol@nvidia.com>
To: "edumazet@google.com" <edumazet@google.com>
Cc: Leon Romanovsky <leonro@nvidia.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"steffen.klassert@secunet.com" <steffen.klassert@secunet.com>,
	"fw@strlen.de" <fw@strlen.de>
Subject: Re: [PATCH net] net: drop secpath extension before skb deferral free
Date: Mon, 20 May 2024 10:06:24 +0000	[thread overview]
Message-ID: <14d383ebd61980ecf07430255a2de730257d3dde.camel@nvidia.com> (raw)
In-Reply-To: <CANn89i+BGcnzJutnUFm_y-Xx66gBCh0yhgq_umk5YFMuFf6C4g@mail.gmail.com>

On Tue, 2024-05-14 at 10:51 +0200, Eric Dumazet wrote:
> On Tue, May 14, 2024 at 9:37 AM Jianbo Liu <jianbol@nvidia.com>
> wrote:
> > 
> > On Mon, 2024-05-13 at 12:29 +0200, Eric Dumazet wrote:
> > > On Mon, May 13, 2024 at 12:04 PM Jianbo Liu <jianbol@nvidia.com>
> > > wrote:
> > > 
> > > 
...
> > > This attribution and patch seem wrong. Also you should CC XFRM
> > > maintainers.
> > > 
> > > Before being freed from tcp_recvmsg() path, packets can sit in
> > > TCP
> > > receive queues for arbitrary amounts of time.
> > > 
> > > secpath_reset() should be called much earlier than in the code
> > > you
> > > tried to change.
> > 
> > Yes, this also fixed the issue if I moved secpatch_reset() before
> > tcp_v4_do_rcv().
> > 
> > --- a/net/ipv4/tcp_ipv4.c
> > +++ b/net/ipv4/tcp_ipv4.c
> > @@ -2314,6 +2314,7 @@ int tcp_v4_rcv(struct sk_buff *skb)
> >         tcp_v4_fill_cb(skb, iph, th);
> > 
> >         skb->dev = NULL;
> > +       secpath_reset(skb);
> > 
> >         if (sk->sk_state == TCP_LISTEN) {
> >                 ret = tcp_v4_do_rcv(sk, skb);
> > 
> > Do you want me to send v2, or push a new one if you agree with this
> > change?
> 
> That would only care about TCP and IPv4.
> 
> I think we need a full fix, not a partial work around to an immediate
> problem.
> 
> Can we have some feedback from Steffen, I  wonder if we missed
> something really obvious.
> 
> It is hard to believe this has been broken for such  a long time.

Could you please give me some suggestions?
Should I add new function to reset both ct and secpath, and replace
nf_reset_ct() where necessary on receive flow?

> 
> I think the issue came with
> 
> commit d77e38e612a017480157fe6d2c1422f42cb5b7e3
> Author: Steffen Klassert <steffen.klassert@secunet.com>
> Date:   Fri Apr 14 10:06:10 2017 +0200
> 
>     xfrm: Add an IPsec hardware offloading API
> 
>     This patch adds all the bits that are needed to do
>     IPsec hardware offload for IPsec states and ESP packets.
>     We add xfrmdev_ops to the net_device. xfrmdev_ops has
>     function pointers that are needed to manage the xfrm
>     states in the hardware and to do a per packet
>     offloading decision.
> 
>     Joint work with:
>     Ilan Tayari <ilant@mellanox.com>
>     Guy Shapiro <guysh@mellanox.com>
>     Yossi Kuperman <yossiku@mellanox.com>
> 
>     Signed-off-by: Guy Shapiro <guysh@mellanox.com>
>     Signed-off-by: Ilan Tayari <ilant@mellanox.com>
>     Signed-off-by: Yossi Kuperman <yossiku@mellanox.com>
>     Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> 
> We should probably handle NETDEV_DOWN/NETDEV_UNREGISTER better,
> instead of adding  secpath_reset(skb) there and there.


  parent reply	other threads:[~2024-05-20 10:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-13 10:02 [PATCH net] net: drop secpath extension before skb deferral free Jianbo Liu
2024-05-13 10:29 ` Eric Dumazet
2024-05-14  7:37   ` Jianbo Liu
2024-05-14  8:51     ` Eric Dumazet
2024-05-15  3:10       ` Jianbo Liu
2024-05-20 10:06       ` Jianbo Liu [this message]
2024-05-21 10:15         ` Steffen Klassert
2024-05-22  9:34         ` Steffen Klassert
2024-05-22 11:06           ` Eric Dumazet
2024-05-23  2:22           ` Jianbo Liu
2024-05-23  6:44             ` Steffen Klassert
2024-05-23  6:57               ` Jianbo Liu
2024-05-23 10:00                 ` Steffen Klassert
2024-05-23 15:26                   ` Jianbo Liu
2024-05-27  7:40                     ` Steffen Klassert
2024-05-28  8:44                       ` Steffen Klassert
2024-05-28  9:02                         ` Jianbo Liu
2024-05-28  9:26                           ` Steffen Klassert
2024-05-26 10:57               ` Leon Romanovsky

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=14d383ebd61980ecf07430255a2de730257d3dde.camel@nvidia.com \
    --to=jianbol@nvidia.com \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=leonro@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.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.