linux-kernel - Re: [PATCH] sparc: Use vmemmap_populate_hugepages for vmemmap

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: <aUP--JzrvOm1-Q2P@kernel.org>
Date: Thu, 18 Dec 2025 15:17:44 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Tao pilgrim <pilgrimtao@...il.com>
Cc: davem@...emloft.net, andreas@...sler.com, akpm@...ux-foundation.org,
	david@...nel.org, lorenzo.stoakes@...cle.com,
	Liam.Howlett@...cle.com, vbabka@...e.cz, surenb@...gle.com,
	mhocko@...e.com, kevin.brodsky@....com, dave.hansen@...ux.intel.com,
	ziy@...dia.com, chengkaitao@...inos.cn, willy@...radead.org,
	zhengqi.arch@...edance.com, sparclinux@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] sparc: Use vmemmap_populate_hugepages for
 vmemmap_populate

On Thu, Dec 18, 2025 at 08:29:27PM +0800, Tao pilgrim wrote:
> On Thu, Dec 18, 2025 at 8:11 PM Mike Rapoport <rppt@...nel.org> wrote:
> >
> > On Thu, Dec 18, 2025 at 07:45:52PM +0800, Tao pilgrim wrote:
> > > On Thu, Dec 18, 2025 at 7:14 PM Mike Rapoport <rppt@...nel.org> wrote:
> > > >
> > > > On Wed, Dec 17, 2025 at 08:08:58PM +0800, chengkaitao wrote:
> > > > > From: Chengkaitao <chengkaitao@...inos.cn>
> > > > >
> > > > > 1. Added the vmemmap_false_pmd function to accommodate architectures
> > > > > that do not support basepages.
> > > > > 2. In the SPARC architecture, reimplemented vmemmap_populate using
> > > > > vmemmap_populate_hugepages.
> > > >
> > > > What problem this patch is trying to solve?
> > >
> > > Following the pattern established by other architectures, vmemmap_populate
> > > is reimplemented using vmemmap_populate_hugepages in the SPARC architecture,
> > > which fulfills the intended purpose of vmemmap_populate_hugepages.
> >
> > But what's wrong with the current sparc::vmemmap_populate()?
> 
> The current implementation of sparc::vmemmap_populate() is correct
> and functional.
> 
> However, I believe that generalizing vmemmap_populate_hugepages()
> still results in certain architectures requiring special-case handling
> branches, which is contrary to our goal of a unified implementation.
> 
> Another benefit is that it allows us to eliminate the external
> declarations of vmemmap_p?d_populate functions and convert
> them to static functions.

If the goals are to provide a unified implementation and eliminate the
external declarations of vmemmap_p?d_populate() functions, I'd suggest to
send all this a single series rather than a single patch that updates sparc
implementation.

Regarding the ability of sparc to fallback to vmemmap_populate_basepages(),
it does not seem to me that this is an architectural limitation. sparc uses
base pages in the kernel page tables, so it should be able to use them in
vmemmap as well.
 
> > > The functional logic remains unchanged.
> > >
> > > > > Signed-off-by: Chengkaitao <chengkaitao@...inos.cn>
> > > > > ---
> 
> -- 
> Yours,
> Kaitao Cheng

-- 
Sincerely yours,
Mike.