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

[Kiryl Shutsemau]

On Fri, Sep 18, 2026 at 10:52:14AM +0800, Lance Yang wrote:
> 
> 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>

Reviewed-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>

-- 
  Kiryl Shutsemau / Kirill A. Shutemov