netdev - Re: [PATCH net-next 05/12] mm: Make the page_frag_cache allocator handle __GFP

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230526175736.7e75dcf9@kernel.org>
Date: Fri, 26 May 2023 17:57:36 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Willem de
 Bruijn <willemdebruijn.kernel@...il.com>, David Ahern <dsahern@...nel.org>,
 Matthew Wilcox <willy@...radead.org>, Jens Axboe <axboe@...nel.dk>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org, Jeroen de Borst
 <jeroendb@...gle.com>, Catherine Sullivan <csully@...gle.com>, Shailend
 Chand <shailend@...gle.com>, Felix Fietkau <nbd@....name>, John Crispin
 <john@...ozen.org>, Sean Wang <sean.wang@...iatek.com>, Mark Lee
 <Mark-MC.Lee@...iatek.com>, Lorenzo Bianconi <lorenzo@...nel.org>, Matthias
 Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
 <angelogioacchino.delregno@...labora.com>, Keith Busch <kbusch@...nel.org>,
 Jens Axboe <axboe@...com>, Christoph Hellwig <hch@....de>, Sagi Grimberg
 <sagi@...mberg.me>, Chaitanya Kulkarni <kch@...dia.com>, Andrew Morton
 <akpm@...ux-foundation.org>, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org, linux-nvme@...ts.infradead.org,
 Alexander Duyck <alexander.duyck@...il.com>
Subject: Re: [PATCH net-next 05/12] mm: Make the page_frag_cache allocator
 handle __GFP_ZERO itself

On Wed, 24 May 2023 16:33:04 +0100 David Howells wrote:
> Make the page_frag_cache allocator handle __GFP_ZERO itself rather than
> passing it off to the page allocator.  There may be a mix of callers, some
> specifying __GFP_ZERO and some not - and even if all specify __GFP_ZERO, we
> might refurbish the page, in which case the returned memory doesn't get
> cleared.

I think it's pretty clear that page frag allocator was never supposed
to support GFP_ZERO, as we don't need it in networking.. So maybe
you're better off adding the memset() in nvme?

CCing Alex, who I think would say something along those lines :)
IDK how much we still care given that most networking drivers are
migrating to page_poll these days.