linux-kernel - Re: [PATCH 18/18] mm, netmem: remove the page pool members in struct 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <187e12ce-7e25-4fe0-871d-170f22125f8e@gmail.com>
Date: Wed, 28 May 2025 08:21:00 +0100
From: Pavel Begunkov <asml.silence@...il.com>
To: Mina Almasry <almasrymina@...gle.com>
Cc: Byungchul Park <byungchul@...com>, willy@...radead.org,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 kernel_team@...ynix.com, kuba@...nel.org, ilias.apalodimas@...aro.org,
 harry.yoo@...cle.com, hawk@...nel.org, akpm@...ux-foundation.org,
 davem@...emloft.net, john.fastabend@...il.com, andrew+netdev@...n.ch,
 toke@...hat.com, tariqt@...dia.com, edumazet@...gle.com, pabeni@...hat.com,
 saeedm@...dia.com, leon@...nel.org, ast@...nel.org, daniel@...earbox.net,
 david@...hat.com, lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com,
 vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com, mhocko@...e.com,
 horms@...nel.org, linux-rdma@...r.kernel.org, bpf@...r.kernel.org,
 vishal.moola@...il.com
Subject: Re: [PATCH 18/18] mm, netmem: remove the page pool members in struct
 page

On 5/27/25 18:38, Mina Almasry wrote:
...>>>> struct netmem_desc *page_to_netmem_desc(struct page *page)
>>>> {
>>>>       return &page->netmem_desc;
>>>
>>> page will not have any netmem things in it after this, that matters.
>>
>> Ok, the question is where are you going to stash the fields?
>> We still need space to store them. Are you going to do the
>> indirection mm folks want?
>>
> 
> I think I see some confusion here. I'm not sure indirection is what mm
> folks want. The memdesc effort has already been implemented for zpdesc

To the best of my knowledge, it is. What you're looking at should be
a temporary state before all other users are converted, after which
mm will shrink the page in a single patch / small series.

> and ptdesc[1], and the approach they did is very different from this
> series. zpdesc and ptdesc have created a struct that mirrors the
> entirety of struct page, not a subfield of struct page with
> indirection:
> 
> https://elixir.bootlin.com/linux/v6.14.3/source/mm/zpdesc.h#L29
> 
> I'm now a bit confused, because the code changes in this series do not
> match the general approach that zpdesc and ptdesc have done.

In my estimation, the only bits that mm needs for a clean final
patch is a new struct with use case specific fields (i.e. netmem_desc),
a helper converting a page to it, and that everyone uses the helper
to access the fields. I'd argue a temporary placeholder in struct
page is an easier approach than separate overlays, but either is
fine to me.

> Byungchul, is the deviation in approach from zpdesc and ptdecs
> intentional? And if so why? Should we follow the zpdesc and ptdesc
> lead and implement a new struct that mirrors the entirety of struct
> page?
> 
> [1] https://kernelnewbies.org/MatthewWilcox/Memdescs/Path

-- 
Pavel Begunkov