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.
>
next prev parent 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®