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

[Zi Yan]

On 28 Oct 2026, at 16:34, David Hildenbrand (Arm) wrote:

> On 10/28/26 18:49, Zi Yan wrote:
>> On 28 Oct 2026, at 4:43, David Hildenbrand (Arm) wrote:
>>
>>>>
>>>> For writable path, a new vmf_insert_pfn_mkwrite() is needed, so it was
>>>> not fixed. I can fix that part as well.
>>>
>>> We should do that; returning kernel allocations from this function in ->fault is
>>> bad.
>>>
>>> How urgent is this fix here? (can it actually be triggered?Specific hardware?)
>>>
>>
>> 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.
>>
>>>>
>>>> The read-only zero page part might need more attention, since
>>>> we just prevented vmf_insert_pfn_prot() from using zero_page. Do we want
>>>> to add the support for rdma_umap_fault()?
>>>
>>> We just have to make sure that we cannot install it writable etc. But that's not
>>> a concern.
>>>
>>> Just have to be careful :)
>>
>> 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.

Best Regards,
Yan, Zi