linux-kernel - Re: [PATCH RFC 2/2] mm: add PMD-level huge page support for remap_pfn

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: <8313b0c1-bf62-4257-951c-fd7e29193ae2@huawei.com>
Date: Thu, 25 Sep 2025 09:43:37 +0800
From: Yin Tirui <yintirui@...wei.com>
To: David Hildenbrand <david@...hat.com>, <akpm@...ux-foundation.org>,
	<lorenzo.stoakes@...cle.com>, <Liam.Howlett@...cle.com>, <vbabka@...e.cz>,
	<rppt@...nel.org>, <surenb@...gle.com>, <mhocko@...e.com>, <ziy@...dia.com>,
	<baolin.wang@...ux.alibaba.com>, <npache@...hat.com>, <ryan.roberts@....com>,
	<dev.jain@....com>, <baohua@...nel.org>, <catalin.marinas@....com>,
	<will@...nel.org>, <paul.walmsley@...ive.com>, <palmer@...belt.com>,
	<aou@...s.berkeley.edu>, <alex@...ti.fr>, <anshuman.khandual@....com>,
	<yangyicong@...ilicon.com>, <ardb@...nel.org>, <willy@...radead.org>,
	<apopple@...dia.com>, <samuel.holland@...ive.com>,
	<luxu.kernel@...edance.com>, <abrestic@...osinc.com>,
	<yongxuan.wang@...ive.com>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-riscv@...ts.infradead.org>
CC: <wangkefeng.wang@...wei.com>, <chenjun102@...wei.com>
Subject: Re: [PATCH RFC 2/2] mm: add PMD-level huge page support for
 remap_pfn_range()



On 9/24/2025 5:50 PM, David Hildenbrand wrote:
>> Introduce pfnmap_max_page_shift parameter to control maximum page
>> size and "nohugepfnmap" boot option to disable huge pfnmap entirely.
> 
> Why? If an arch supports it we should just do it. Or what's the reason 
> behind that?
> 
There's no specific reason for this - it was just intended to provide an 
additional option. I'll remove it in the next version.

...
> Are you sure we can just entirely remove this block for ! 
> vma_is_anonymous(vma)?
>
Thank you for pointing this out!
There is definitely a problem with removing this block entirely for 
non-anonymous VMAs. I've also found some other problems. I'll fix all of 
them in the next version.

-- 
Best regards,
Yin Tirui