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

[Lance Yang]

On Fri, Sep 18, 2026 at 10:37:27PM +0200, David Hildenbrand (Arm) wrote:
>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.

Ah I see, thanks! obviously, I hadn't fully understood that ...

How about this instead?

"
Handling the huge/shared zeropage correctly in vmf_insert_pfn_pmd()
and vmf_insert_pfn_prot() is more involved. We would need to check
whether the VMA allows it and keep the mapping read-only, similar
to the checks in vm_mixed_ok().

No in-tree user needs that support, so reject these mappings with
VM_FAULT_SIGBUS rather than complicate the code for now.
"

Thanks, Lance

>> 
>> 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>
>> ---
>
>-- 
>Cheers,
>
>David
>