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

[Leon Romanovsky]

On Wed, Oct 28, 2026 at 01:49:23PM -0400, Zi Yan wrote:
> On 28 Oct 2026, at 4:43, David Hildenbrand (Arm) wrote:
> 
> >>>> +	/*
> >>>> +	 * VMAs that cannot become writable map the page as a raw pfn, like
> >>>> +	 * the device memory it replaces. The page lives as long as the file.
> >>>> +	 */
> >>>> +	if (!(vmf->vma->vm_flags & (VM_WRITE | VM_MAYWRITE))) {
> >>>> +		ret = vmf_insert_pfn(vmf->vma, vmf->address, page_to_pfn(page));
> >>>> +		goto out;
> >>>> +	}
> >>>> +
> >>>> +	/*
> >>>> +	 * This VMA is forced to always be shared so this doesn't have
> >>>> +	 * to worry about COW.
> >>>> +	 */
> >>>> +	vmf->page = page;
> >>>> +	get_page(page);
> >>>
> >>>
> >>> This split handling is pretty horrible TBH.
> >>>
> >>> In once case we take a reference in the other not?
> >>>
> >>> Why not perform a PFN mapping in any case?
> >>
> >> 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.
> 
> Jason, is RDMA supported on s390? 

Yes