[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKhg4tLnSOxB7eeMqna1K3cmOn30cofxH=duOPLRs0h+59j01w@mail.gmail.com>
Date: Wed, 5 Apr 2023 16:18:47 +0800
From: Liang Chen <liangchen.linux@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Alexander H Duyck <alexander.duyck@...il.com>,
ilias.apalodimas@...aro.org, hawk@...nel.org, davem@...emloft.net,
edumazet@...gle.com, pabeni@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH] skbuff: Fix a race between coalescing and releasing SKBs
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.
Powered by blists - more mailing lists