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

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

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.

(have to make sure that gup-fast doesn't try pinning the shared zeropage)

(of course, the shared zeropage must never get mapped writable)

-- 
Cheers,

David