Re: [PATCH 1/1] mm/huge_memory: disallow raw PMD mappings of the huge zero page

[Lance Yang]

On Thu, Sep 17, 2026 at 05:03:09PM +0100, Kiryl Shutsemau wrote:
>On Thu, Sep 17, 2026 at 05:29:48PM +0200, David Hildenbrand (Arm) wrote:
>> On 9/17/26 16:32, Kiryl Shutsemau wrote:
>> > On Thu, Sep 17, 2026 at 08:10:10PM +0800, Lance Yang wrote:
>> >> vm_mixed_zeropage_allowed() validates zeropage insertion into
>> >> VM_MIXEDMAP VMAs. No in-tree user needs to insert the huge zero page
>> >> through vmf_insert_pfn_pmd().
>> >>
>> >> Return VM_FAULT_SIGBUS if vmf_insert_pfn_pmd() is asked to map it.
>> >>
>> >> Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@xxxxxxxxxx/
>> >> Suggested-by: Kiryl Shutsemau <kas@xxxxxxxxxx>
>> >> Suggested-by: David Hildenbrand <david@xxxxxxxxxx>
>> >> Signed-off-by: Lance Yang <lance.yang@xxxxxxxxx>
>> > 
>> > The patch looks fine, but don't we want to cover the same for non-huge
>> > zero page in vmf_insert_pfn_prot()?
>> 
>> Why would the zeropage be a problem in PFNMAP mapping?
>
>Nothing enforces that it is read-only.

No in-tree user inserts the zeropage through vmf_insert_pfn_prot(), so
rejecting it there should be fine.

Something like:

---8<---
The huge zeropage is reclaimable, but a raw PFN mapping does not pin it.
A PMD mapping of huge_zero_pfn can therefore outlive the folio.

No in-tree user needs either mapping, so reject both with VM_FAULT_SIGBUS
rather than risk making either shared zero page writable.

Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@xxxxxxxxxx/
Suggested-by: Kiryl Shutsemau <kas@xxxxxxxxxx>
Suggested-by: David Hildenbrand <david@xxxxxxxxxx>
Signed-off-by: Lance Yang <lance.yang@xxxxxxxxx>
---

 mm/huge_memory.c | 3 +++
 mm/memory.c      | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index b49bffe36d22..de34d64aa763 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1723,6 +1723,9 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, unsigned long pfn,
 						(VM_PFNMAP|VM_MIXEDMAP));
 	BUG_ON((vma->vm_flags & VM_PFNMAP) && vma_is_cow_mapping(vma));

+	if (unlikely(is_huge_zero_pfn(pfn)))
+		return VM_FAULT_SIGBUS;
+
 	pfnmap_setup_cachemode_pfn(pfn, &pgprot);

 	return insert_pmd(vma, addr, vmf->pmd, fop, pgprot, write);
diff --git a/mm/memory.c b/mm/memory.c
index 9e4a70421a6b..5d2d73c69fed 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2956,6 +2956,9 @@ vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
 	BUG_ON((vma->vm_flags & VM_PFNMAP) && vma_is_cow_mapping(vma));
 	BUG_ON((vma->vm_flags & VM_MIXEDMAP) && pfn_valid(pfn));

+	if (unlikely(is_zero_pfn(pfn)))
+		return VM_FAULT_SIGBUS;
+
 	if (addr < vma->vm_start || addr >= vma->vm_end)
 		return VM_FAULT_SIGBUS;

--

That would keep both zeropages out of writable raw-PFN fault mappings ...
wdyt?

Cheers, Lance