netdev - Re: [RFC] shrinking struct page (part of page 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: <20250416102015.GA5520@system.software.com>
Date: Wed, 16 Apr 2025 19:20:15 +0900
From: Byungchul Park <byungchul@...com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: willy@...radead.org, ilias.apalodimas@...aro.org,
	almasrymina@...gle.com, kernel_team@...ynix.com,
	42.hyeyoo@...il.com, linux-mm@...ck.org, hawk@...nel.org,
	netdev@...r.kernel.org
Subject: Re: [RFC] shrinking struct page (part of page pool)

On Mon, Apr 14, 2025 at 04:30:02PM -0700, Jakub Kicinski wrote:
> On Mon, 14 Apr 2025 10:52:07 +0900 Byungchul Park wrote:
> > > Fortunately, many prerequisite works have been done by Mina but I guess
> > > he or she has done it for other purpose than 'shrinking struct page'.
> > > 
> > > I'd like to just finalize the work so that the fields above can be
> > > removed from struct page.  However, I need to resolve a curiousity
> > > before starting.
> 
> I don't understand what the question is but FWIW from my perspective
> the ZC APIs are fairly contained, or at least we tried to make sure
> that net_iov pages cannot reach random parts of the stack.
> 
> Replacing all uses of struct page would require converting much more
> of the stack, AFAIU. But that's best discussed over posted patches.

Okay.  Let's discuss it once posting patches.

> > >    Network guys already introduced a sperate strcut, struct net_iov,
> > >    to overlay the interesting fields.  However, another separate struct
> > >    for system memory might be also needed e.g. struct bump so that
> > >    struct net_iov and struct bump can be overlayed depending on the
> > >    source:
> > > 
> > >    struct bump {
> > > 	unsigned long _page_flags;
> > > 	unsigned long bump_magic;
> > > 	struct page_pool *bump_pp;
> > > 	unsigned long _pp_mapping_pad;
> > > 	unsigned long dma_addr;
> > > 	atomic_long_t bump_ref_count;
> > > 	unsigned int _page_type;
> > > 	atomic_t _refcount;
> > >    };
> > > 
> > > To netwrok guys, any thoughts on it?
> > > To Willy, do I understand correctly your direction?
> > > 
> > > Plus, it's a quite another issue but I'm curious, that is, what do you
> > > guys think about moving the bump allocator(= page pool) code from
> > > network to mm?  I'd like to start on the work once gathering opinion
> > > from both Willy and network guys.
> 
> I don't see any benefit from moving page pool to MM. It is quite
> networking specific. But we can discuss this later. Moving code
> is trivial, it should not be the initial focus.

I think so.

	Byungchul