Received-SPF: pass (google.com: domain of linux-kernel+bounces-94147-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 6 Mar 2024 07:22:25 -0800
From: Jakub Kicinski <kuba@kernel.org>
To: Dragos Tatulea <dtatulea@nvidia.com>
Cc: "almasrymina@google.com" <almasrymina@google.com>, "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>, Leon Romanovsky <leonro@nvidia.com>,
 "pabeni@redhat.com" <pabeni@redhat.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
Message-ID: <20240306072225.4a61e57c@kernel.org>
In-Reply-To: <7fc334b847dc4d90af796f84a8663de9f43ede5d.camel@nvidia.com>
References: <20240304094950.761233-1-dtatulea@nvidia.com>
	<20240305190427.757b92b8@kernel.org>
	<7fc334b847dc4d90af796f84a8663de9f43ede5d.camel@nvidia.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, 6 Mar 2024 13:05:14 +0000 Dragos Tatulea wrote:
> On Tue, 2024-03-05 at 19:04 -0800, Jakub Kicinski wrote:
> > On Mon, 4 Mar 2024 11:48:52 +0200 Dragos Tatulea wrote: =20
> > > When the skb is reorganized during esp_output (!esp->inline), the pag=
es
> > > coming from the original skb fragments are supposed to be released ba=
ck
> > > to the system through put_page. But if the skb fragment pages are
> > > originating from a page_pool, calling put_page on them will trigger a
> > > page_pool leak which will eventually result in a crash. =20
> >=20
> > So it just does: skb_shinfo(skb)->nr_frags =3D 1;
> > and assumes that's equivalent to owning a page ref on all the frags?
> >  =20
> My understanding is different: it sets nr_frags to 1 because it's swappin=
g out
> the old page frag in fragment 0 with the new xfrag page frag and will use=
 this
> "new" skb from here. It does take a page reference for the xfrag page fra=
g.

Same understanding, I'm just bad at explaining :)

> > Fix looks more or less good, we would need a new wrapper to avoid
> > build issues without PAGE_POOL,=C2=A0
> >  =20
> Ack. Which component would be best location for this wrapper: page_pool?

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.

> > but I wonder if we wouldn't be better
> > off changing the other side. Instead of "cutting off" the frags -
> > walking them and dealing with various page types. Because Mina and co.
> > will step onto this landmine as well. =20
> The page frags are still stored and used in the sg scatterlist. If we rel=
ease
> them at the moment when the skb is "cut off", the pages in the sg will be
> invalid. At least that's my understanding.

I was thinking something along the lines of:

	for each frag()
		if (is_pp_page()) {
			get_page();
			page_pool_unref_page(1);
		}

so that it's trivial to insert another check for "is this a zero-copy"
page in there, and error our. But on reflection the zero copy check may
be better placed in __skb_to_sgvec(), so ignore this. Just respin
what you got with a new helper.