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

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

On 9/19/26 17:14, Lance Yang wrote:
> 
> On Fri, Sep 18, 2026 at 10:37:27PM +0200, David Hildenbrand (Arm) wrote:
>> On 9/18/26 04:52, Lance Yang wrote:
>>>
>>>
>>> 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.
> "

Works for me.

-- 
Cheers,

David