[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA85sZtAixvRQnzs5+nad_pFsN9VZ67a2_CLCPFrHfieijn18A@mail.gmail.com>
Date: Fri, 7 Jul 2023 00:41:17 +0200
From: Ian Kumlien <ian.kumlien@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Eric Dumazet <edumazet@...gle.com>,
Willem de Bruijn <willemb@...gle.com>,
Alexander Lobakin <aleksander.lobakin@...el.com>,
intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
Jakub Kicinski <kuba@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Intel-wired-lan] bug with rx-udp-gro-forwarding offloading?
On Fri, Jul 7, 2023 at 12:32 AM Ian Kumlien <ian.kumlien@...il.com> wrote:
> On Thu, Jul 6, 2023 at 7:10 PM Paolo Abeni <pabeni@...hat.com> wrote:
> > Let me try to clarify: I hope/think that this chunk alone:
> >
> > + /* later code will clear the gso area in the shared info */
> > + err = skb_header_unclone(skb, GFP_ATOMIC);
> > + if (err)
> > + goto err_linearize;
> > +
> > skb_shinfo(skb)->frag_list = NULL;
> >
> > while (list_skb) {
> >
> > does the magic/avoids the skb corruptions -> it everything goes well,
> > you should not see any warnings at all. Running 'nstat' in the DUT
> > should give some hints about reaching the relevant code paths.
Ah yeah... I'm a bit tired atm - I see your point - with moving it up a bit.
So anyway, Tested-by: ian.kumlien@...il.com etc =)
Powered by blists - more mailing lists