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]
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 :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ