All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Dragos Tatulea <dtatulea@nvidia.com>
To: "kuba@kernel.org" <kuba@kernel.org>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"ilias.apalodimas@linaro.org" <ilias.apalodimas@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jacob.e.keller@intel.com" <jacob.e.keller@intel.com>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	Jianbo Liu <jianbol@nvidia.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"almasrymina@google.com" <almasrymina@google.com>,
	"edumazet@google.com" <edumazet@google.com>
Subject: Re: [RFC PATCH] net: Fix one page_pool page leak from skb_frag_unref
Date: Mon, 29 Apr 2024 07:39:09 +0000	[thread overview]
Message-ID: <c307a3086d255d1dfed22284f500aa9fb70f11a3.camel@nvidia.com> (raw)
In-Reply-To: <20240426160557.51de91f9@kernel.org>

On Fri, 2024-04-26 at 16:05 -0700, Jakub Kicinski wrote:
> On Thu, 25 Apr 2024 08:17:28 +0000 Dragos Tatulea wrote:
> > >  The unref path always dropped a regular page
> > > ref, thanks to this commit as you point out:
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2cc3aeb5ecccec0d266813172fcd82b4b5fa5803
> > > 
> > > AFAICT the correct fix is to actually revert commit 2cc3aeb5eccc
> > > ("skbuff: Fix a potential race while recycling page_pool packets").
> > > The reason is that now that skb_frag_ref() can grab page-pool refs, we
> > > don't need to make sure there is only 1 SKB that triggers the recycle
> > > path anymore. All the skb and its clones can obtain page-pool refs,
> > > and in the unref path we drop the page-pool refs. page_pool_put_page()
> > > detects correctly that the last page-pool ref is put and recycles the
> > > page only then.
> > >   
> > I don't think this is a good way forward. For example, skb->pp_recycle is used
> > as a hint in skb_gro_receive to avoid coalescing skbs with different pp_recycle
> > flag states. This could interfere with that.
> 
> That's a bit speculative, right? The simple invariant we are trying to
> hold is that if skb->pp_recycle && skb_frag_is_pp(skb, i) then the
> reference skb is holding on that frag is a pp reference, not page
> reference.
> 
Yes, it was a speculative statement. After re-reading it and the code of
skb_gro_receive() it makes less sense now.

Mina's suggestion to revert commit 2cc3aeb5eccc ("skbuff: Fix a potential race
while recycling page_pool packets") seems less scary now. I just hope we don't
bump into too many scenarios similar to the ipsec one...

> skb_gro_receive() needs to maintain that invariant, if it doesn't
> we need to fix it..
> 

Thanks,
Dragos

  reply	other threads:[~2024-04-29  7:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24 16:56 [RFC PATCH] net: Fix one page_pool page leak from skb_frag_unref Dragos Tatulea
2024-04-24 17:25 ` Dragos Tatulea
2024-04-24 22:08   ` Mina Almasry
2024-04-25  8:17     ` Dragos Tatulea
2024-04-25 19:20       ` Mina Almasry
2024-04-25 19:47         ` Dragos Tatulea
2024-04-25 20:42           ` Mina Almasry
2024-04-26 14:59             ` Dragos Tatulea
2024-04-26 19:03               ` Mina Almasry
2024-04-26 23:08         ` Jakub Kicinski
2024-04-27  4:24           ` Mina Almasry
2024-04-29 15:00             ` Jakub Kicinski
2024-05-02 20:08               ` Mina Almasry
2024-05-03  0:46                 ` Jakub Kicinski
2024-04-26 23:05       ` Jakub Kicinski
2024-04-29  7:39         ` Dragos Tatulea [this message]
2024-05-01  6:20           ` Dragos Tatulea
2024-05-01  7:48             ` Mina Almasry
2024-05-01  7:58               ` Dragos Tatulea
2024-05-01 14:24               ` Jakub Kicinski
2024-05-01 14:28                 ` Jakub Kicinski
2024-05-01 16:23                 ` Mina Almasry
2024-04-26 23:07     ` Jakub Kicinski

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=c307a3086d255d1dfed22284f500aa9fb70f11a3.camel@nvidia.com \
    --to=dtatulea@nvidia.com \
    --cc=almasrymina@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jianbol@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.