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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 9/18/26 04:52, 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:
>>>
>>> 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.

Well, just with any other folio that we PFNMAP, the mapping would have to hold a
reference. mm_get_huge_zero_folio() can be used for that, or just grabbing a
folio reference (not so nice, but works; GUP uses that, for example, to keep the
huge zero folio alive).

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

That is the better reason. You could also just say that handling shared
zeropages correctly is more involved (see vm_mixed_ok()), and as there are no
users, we can just disallow it instead of trying to fix it.

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

-- 
Cheers,

David