netdev - Re: [RFC PATCH net-next] page_pool: Track DMA-mapped pages and unmap them when destroying the pool

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: <87ldtbinwe.fsf@toke.dk>
Date: Tue, 11 Mar 2025 16:32:17 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Yunsheng Lin <yunshenglin0825@...il.com>, Andrew Morton
 <akpm@...ux-foundation.org>, Jesper Dangaard Brouer <hawk@...nel.org>,
 Ilias Apalodimas <ilias.apalodimas@...aro.org>, "David S. Miller"
 <davem@...emloft.net>, Yunsheng Lin <linyunsheng@...wei.com>, Yonglong Liu
 <liuyonglong@...wei.com>, Mina Almasry <almasrymina@...gle.com>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 linux-mm@...ck.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH net-next] page_pool: Track DMA-mapped pages and
 unmap them when destroying the pool

Matthew Wilcox <willy@...radead.org> writes:

> On Mon, Mar 10, 2025 at 06:26:23PM +0100, Toke Høiland-Jørgensen wrote:
>> Matthew Wilcox <willy@...radead.org> writes:
>> > See https://kernelnewbies.org/MatthewWilcox/Memdescs
>> > and more immediately
>> > https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
>> >
>> > pagepool is going to be renamed "bump" because it's a bump allocator and
>> > "pagepool" is a nonsense name.  I haven't looked into it in a lot of
>> > detail yet, but in the not-too-distant future, struct page will look
>> > like this (from your point of view):
>> >
>> > struct page {
>> > 	unsigned long flags;
>> > 	unsigned long memdesc;
>> > 	int _refcount;	// 0 for bump
>> > 	union {
>> > 		unsigned long private;
>> > 		atomic_t _mapcount; // maybe used by bump?  not sure
>> > 	};
>> > };
>> >
>> > 'memdesc' will be a pointer to struct bump with the bottom four bits of
>> > that pointer indicating that it's a struct bump pointer (and not, say, a
>> > folio or a slab).
>> >
>> > So if you allocate a multi-page bump, you'll get N of these pages,
>> > and they'll all point to the same struct bump where you'll maintain
>> > your actual refcount.  And you'll be able to grow struct bump to your
>> > heart's content.  I don't know exactly what struct bump looks like,
>> > but the core mm will have no requirements on you.
>> 
>> Ah, excellent, thanks for the pointer!
>> 
>> Out of curiosity, why "bump"? Is that a term of art somewhere?
>
> https://en.wikipedia.org/wiki/Region-based_memory_management
>
> (and the term "bump allocator" has a number of hits in your favourite
> search engine)

Right, fair point, I was being lazy by just asking. Thanks for taking
the time to provide a link :)

>> And in the meantime (until those patches land), do you see any reason
>> why we can't squat on the middle bits of page->pp_magic (AKA page->lru)
>> like I'm doing in v2[0] of this patch?
>
> I haven't had time to dig into this series.  I'm trying to get a bunch
> of things finished before LSFMM.

Alright, well if/when you get a chance (before of after LSFMM), I'd
appreciate if you could take a look!

-Toke