[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAC_iWjJD-g34ABOhu8f9wMLF0a9YYAZdh_uh2Vq44C-fAU3Nag@mail.gmail.com>
Date: Thu, 6 Apr 2023 13:46:18 +0300
From: Ilias Apalodimas <ilias.apalodimas@...aro.org>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Liang Chen <liangchen.linux@...il.com>,
Alexander Duyck <alexander.duyck@...il.com>,
Jakub Kicinski <kuba@...nel.org>, hawk@...nel.org,
davem@...emloft.net, pabeni@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH] skbuff: Fix a race between coalescing and releasing SKBs
On Thu, 6 Apr 2023 at 12:56, Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Thu, Apr 6, 2023 at 5:28 AM Liang Chen <liangchen.linux@...il.com> wrote:
> >
> > On Wed, Apr 5, 2023 at 11:06 PM Alexander Duyck
> > <alexander.duyck@...il.com> wrote:
> > >
> > > On Wed, Apr 5, 2023 at 1:19 AM Liang Chen <liangchen.linux@...il.com> wrote:
> > > >
> > > > On Wed, Apr 5, 2023 at 9:21 AM Jakub Kicinski <kuba@...nel.org> wrote:
> > > > >
> > > > > On Tue, 04 Apr 2023 08:51:18 -0700 Alexander H Duyck wrote:
> > > > > > I'm not quite sure I agree with the fix. Couldn't we just modify the
> > > > > > check further down that does:
> > > > > >
> > > > > > if (!skb_cloned(from))
> > > > > > from_shinfo->nr_frags = 0;
> > > > > >
> > > > > > And instead just make that:
> > > > > > if (!skb->cloned || (!skb_cloned(from) && !from->pp_recycle))
> > > > > > from_shinfo->nr_frags = 0;
> > > > > >
> > > > > > With that we would retain the existing behavior and in the case of
> > > > > > cloned from frames we would take the references and let the original
> > > > > > from skb freed to take care of pulling the pages from the page pool.
> > > > >
> > > > > Sounds like a better fix, indeed. But this sort of code will require
> > > > > another fat comment above to explain why. This:
> > > > >
> > > > > if (to->pp_recycle == from->pp_recycle && !skb_cloned(from))
> > > > >
> > > > > is much easier to understand, no?
> > > > >
> > > > > We should at least include that in the explanatory comment, I reckon...
> > > >
> > > > Sure, the idea of dealing with the case where @from transitioned into non cloned
> > > > skb in the function retains the existing behavior, and gives more
> > > > opportunities to
> > > > coalesce skbs. And it seems (!skb_cloned(from) && !from->pp_recycle) is enough
> > > > here.
> > > > I will take a closer look at the code path for the fragstolen case
> > > > before making v2
> > > > patch - If @from transitioned into non cloned skb before "if
> > > > (skb_head_is_locked(from))"
> > > >
> > > > Thanks for the reviews.
> > >
> > > Actually I am not sure that works now that I look at it closer. The
> > > problem with using (!skb_cloned(from) && !from->pp_recycle) is that it
> > > breaks the case where both from and to are pp_recycle without being
> > > cloned.
> >
> > Yeah, it would break that case. Thanks!
> > >
> > > So it probably needs to be something actually the setup Jakub
> > > suggested would probably work better:
> > > if (to->pp_recycle == from->pp_recycle && !skb_cloned(from))
> > >
> >
> > I agree. That's better.
>
> Same feeling on my side.
> I prefer not trying to merge mixed pp_recycle skbs "just because we
> could" at the expense
> of adding more code in a fast path.
+1 here. The intention of recycling was to affect the normal path as
less as possible. On top of that, we've some amount of race
conditions over the years, trying to squeeze more performance with
similar tricks. I'd much rather be safe here, since recycling by
itself is a great performance boost
Regards
/Ilias
Powered by blists - more mailing lists