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: <20250414163002.166d1a36@kernel.org>
Date: Mon, 14 Apr 2025 16:30:02 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Byungchul Park <byungchul@...com>
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, 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.

> >    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.