mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dragos Tatulea <dtatulea@nvidia.com>
To: "kuba@kernel.org" <kuba@kernel.org>,
	"almasrymina@google.com" <almasrymina@google.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	Gal Pressman <gal@nvidia.com>,
	"dsahern@kernel.org" <dsahern@kernel.org>,
	"steffen.klassert@secunet.com" <steffen.klassert@secunet.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	Leon Romanovsky <leonro@nvidia.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"ian.kumlien@gmail.com" <ian.kumlien@gmail.com>,
	"Anatoli.Chechelnickiy@m.interpipe.biz"
	<Anatoli.Chechelnickiy@m.interpipe.biz>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [RFC] net: esp: fix bad handling of pages from page_pool
Date: Wed, 6 Mar 2024 17:09:57 +0000	[thread overview]
Message-ID: <9a78b37abdf40daafd9936299ea2c08f936ad3d5.camel@nvidia.com> (raw)
In-Reply-To: <CAHS8izMw_hxdoNDoCZs8T7c5kmX=0Lwqw_dboSj7z1LqtS-WKA@mail.gmail.com>

On Wed, 2024-03-06 at 08:40 -0800, Mina Almasry wrote:
> On Wed, Mar 6, 2024 at 8:09 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > 
> > On Wed, 6 Mar 2024 16:00:46 +0000 Dragos Tatulea wrote:
> > > > Hm, that's a judgment call.
> > > > Part of me wants to put it next to napi_frag_unref(), since we
> > > > basically need to factor out the insides of this function.
> > > > When you post the patch the page pool crowd will give us
> > > > their opinions.
> > > 
> > > Why not have napi_pp_put_page simply return false if CONFIG_PAGE_POOL is not
> > > set?
> > 
> > Without LTO it may still be a function call.
> > Plus, subjectively, I think that it's a bit too much logic to encode in
> > the caller (you must also check skb->pp_recycle, AFAIU)
> > Maybe we should make skb_pp_recycle() take struct page and move it to
> > skbuff.h ? Rename it to skb_page_unref() ?
> > 
> 
> Does the caller need to check skb->pp_recycle? pp_recycle seems like a
> redundant bit. We can tell whether the page is pp by checking
> is_pp_page(page). the pages in the frag must be pp pages when
> skb->pp_recycle is set and must be non pp pages when the
> skb->pp_recycle is not set, so it all seems redundant to me.
> 
AFAIU we don't have to check for pp_recycle, at least not in this specific case.

> My fix would be something like:
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index d577e0bee18d..cc737b7b9860 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -3507,17 +3507,25 @@ int skb_cow_data_for_xdp(struct page_pool
> *pool, struct sk_buff **pskb,
>  bool napi_pp_put_page(struct page *page, bool napi_safe);
> 
>  static inline void
> -napi_frag_unref(skb_frag_t *frag, bool recycle, bool napi_safe)
> +napi_page_unref(struct page *page, bool napi_safe)
>  {
> -       struct page *page = skb_frag_page(frag);
> -
>  #ifdef CONFIG_PAGE_POOL
> -       if (recycle && napi_pp_put_page(page, napi_safe))
> +       if (napi_pp_put_page(page, napi_safe))
>                 return;
>  #endif
>         put_page(page);
>  }
> 
> +static inline void
> +napi_frag_unref(skb_frag_t *frag, bool recycle, bool napi_safe)
> +{
> +       struct page *page = skb_frag_page(frag);
> +
> +       DEBUG_NET_WARN_ON(recycle != is_pp_page(page));
> +
> +       napi_page_unref(page);
> +}
> +
> 
> And then use napi_page_unref() in the callers to handle page pool &
> non-page pool gracefully without leaking page pool internals to the
> callers.
> 
We'd also need to add is_pp_page() in the header with the changes above...

On that line of thought, unless these new APIs are useful for other use-cases,
why not keep it simple:
- Move is_pp_page() to skbuff.h.
- Do a simple is_pp_page(page) ? page_pool_put_full_page(page):put_page(page) in
the caller? Checking skb->pp_recycle would not be needed. 

Thanks,
Dragos

> > > Regarding stable would I need to send a separate fix that does the raw pp page
> > > check without the API?
> > 
> > You can put them in one patch, I reckon.
> 


  reply	other threads:[~2024-03-06 17:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-04  9:48 Dragos Tatulea
2024-03-06  3:04 ` Jakub Kicinski
2024-03-06 13:05   ` Dragos Tatulea
2024-03-06 15:22     ` Jakub Kicinski
2024-03-06 16:00       ` Dragos Tatulea
2024-03-06 16:09         ` Jakub Kicinski
2024-03-06 16:40           ` Mina Almasry
2024-03-06 17:09             ` Dragos Tatulea [this message]
2024-03-06 17:27               ` Mina Almasry
2024-03-06 17:41               ` Jakub Kicinski
2024-03-06 18:41                 ` Mina Almasry
2024-03-06 18:46                   ` Mina Almasry
2024-03-07  2:16                     ` 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=9a78b37abdf40daafd9936299ea2c08f936ad3d5.camel@nvidia.com \
    --to=dtatulea@nvidia.com \
    --cc=Anatoli.Chechelnickiy@m.interpipe.biz \
    --cc=almasrymina@google.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=gal@nvidia.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=ian.kumlien@gmail.com \
    --cc=kuba@kernel.org \
    --cc=leonro@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®