linux-kernel - Re: [PATCH net-next 1/9] netmem: introduce struct netmem

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250611185542.118230c1@kernel.org>
Date: Wed, 11 Jun 2025 18:55:42 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Byungchul Park <byungchul@...com>
Cc: willy@...radead.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, kernel_team@...ynix.com,
 almasrymina@...gle.com, 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, asml.silence@...il.com,
 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 net-next 1/9] netmem: introduce struct netmem_desc
 mirroring struct page

On Tue, 10 Jun 2025 10:30:01 +0900 Byungchul Park wrote:
> > What's the intended relation between the types?  
> 
> One thing I'm trying to achieve is to remove pp fields from struct page,
> and make network code use struct netmem_desc { pp fields; } instead of
> sturc page for that purpose.
> 
> The reason why I union'ed it with the existing pp fields in struct
> net_iov *temporarily* for now is, to fade out the existing pp fields
> from struct net_iov so as to make the final form like:

I see, I may have mixed up the complaints there. I thought the effort
was also about removing the need for the ref count. And Rx is
relatively light on use of ref counting. 

> > netmem_ref exists to clearly indicate that memory may not be readable.
> > Majority of memory we expect to allocate from page pool must be
> > kernel-readable. What's the plan for reading the "single pointer"
> > memory within the kernel?
> > 
> > I think you're approaching this problem from the easiest and least  
> 
> No, I've never looked for the easiest way.  My bad if there are a better
> way to achieve it.  What would you recommend?

Sorry, I don't mean that the approach you took is the easiest way out.
I meant that between Rx and Tx handling Rx is the easier part because 
we already have the suitable abstraction. It's true that we use more
fields in page struct on Rx, but I thought Tx is also more urgent
as there are open reports for networking taking references on slab
pages.

In any case, please make sure you maintain clear separation between
readable and unreadable memory in the code you produce.