Re: [PATCH] RDMA/uverbs: Don't return the shared zero page from rdma_umap_fault()

[David Hildenbrand (Arm)]

On 10/29/26 03:00, Zi Yan wrote:
> On 28 Oct 2026, at 16:34, David Hildenbrand (Arm) wrote:
> 
>> On 10/28/26 18:49, Zi Yan wrote:
>>>
>>>
>>> Not urgent. Like Jason said in another email, RDMA only runs on arch
>>> with special PTE, so refcount, mapcount, rss are balanced. With DEBUG_VM,
>>> zero_page checks in rmap will fire on the returned zero_page.
>>>
>>>
>>> There is one wrinkle, it does not work on
>>> s390 + mm_forbids_zeropage() == true, where zero page is not present,
>>> and a private zero page is needed.
>>
>> Yes, see vm_mixed_zeropage_allowed() I added.
>>
>> In a VM_PFNMAP it doesn't matter. It's only a problem if we can GUP involved
>> IIRC, and VM_PFNMAP just disallows it entirely.
>>
>> Similar for s390, it doesn't support any form of memory deduplication (incl.
>> shared zeropage) for some KVM use cases. IIRC, PFNMAP does not really apply there.
> 
> Got it. It is then all clear to modify vmf_insert_pfn_prot() to support
> zeropage for VM_PFNMAP (no huge zeropage support will be added).
> 
>>
>> (have to make sure that gup-fast doesn't try pinning the shared zeropage)
> 
> With special pte, GUP-fast bails out on the PTE. Without special pte,
> gup_fast_pte_range() simply returns 0. Then GUP slow rejects VM_PFNMAP.
> 
>>
>> (of course, the shared zeropage must never get mapped writable)
> 
> vmf_insert_pfn_prot() will only accept a shared zeropage on a VMA if the
> VMA has neither VM_WRITE nor VM_MAYWRITE. It should prevent the VMA
> becoming writable. Also it will ensure the result PTE is not writable.
> 
> As we discussed on IRC, VM_WARN_ON_ONCE_VMA(vma->vm_flags & VM_PFNMAP, vma)
> will be added after __do_fault() to enforce no page is returned
> from ->fault().
> 
> Since it is not urgent, I will probably send V2 after rc1 is out.
> Thank you for all the info.

Thanks for handling this!

-- 
Cheers,

David