linux-kernel - Re: [RFC] net: esp: fix bad handling of pages from page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240306181600.5af8ef5f@kernel.org>
Date: Wed, 6 Mar 2024 18:16:00 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Mina Almasry <almasrymina@...gle.com>
Cc: Liang Chen <liangchen.linux@...il.com>, Yunsheng Lin
 <linyunsheng@...wei.com>, Dragos Tatulea <dtatulea@...dia.com>,
 "davem@...emloft.net" <davem@...emloft.net>, "herbert@...dor.apana.org.au"
 <herbert@...dor.apana.org.au>, Gal Pressman <gal@...dia.com>,
 "dsahern@...nel.org" <dsahern@...nel.org>, "steffen.klassert@...unet.com"
 <steffen.klassert@...unet.com>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
 Leon Romanovsky <leonro@...dia.com>, "edumazet@...gle.com"
 <edumazet@...gle.com>, "ian.kumlien@...il.com" <ian.kumlien@...il.com>,
 "Anatoli.Chechelnickiy@...nterpipe.biz"
 <Anatoli.Chechelnickiy@...nterpipe.biz>, "netdev@...r.kernel.org"
 <netdev@...r.kernel.org>
Subject: Re: [RFC] net: esp: fix bad handling of pages from page_pool

On Wed, 6 Mar 2024 10:46:45 -0800 Mina Almasry wrote:
> Gah, nevermind, skb_pp_frag_ref() actually returns -EINVAL if
> !skb->pp_recycle, and in the call site we do a skb_frag_ref() on this
> error, so all in all we end up doing a get_page/put_page pair. Sorry
> for the noise.
> 
> So we're supposed to:
> - !skb->pp_recycle && is_pp_page()
> ref via get_page
> unref via put_page
> 
> Very subtle stuff (for me at least). I'll try to propose some cleanup
> to make this a bit simpler using helpers that handle all these subtle
> details internally so that the call sites don't have to do this
> special handling.

Sure, although complexity is complexity, we can only do so much to hide
it.

For pp_recycle - the problem is when we added page pool pages, hardly
anything in the upper layers of the stack was made pp aware. So we can
end up with someone doing

	get_page(page);
	skb_fill_page_desc(skb, page);

on a PP page.

You probably inspected a lot of those cases for the ZC work, and they
can be fixed up to do a "pp-aware get()", but until then we need
skb->pp_recycle. pp_recycle kinda denotes whether whoever constructed
the skb was PP aware.

So, yes, definitely a good long term goal, but not in a fix :)