Re: [PATCH] mm/mremap: allow VMAs with VM_DONTEXPAND|VM_PFNMAP when creating new mapping

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

On 11/20/25 10:58, Lorenzo Stoakes wrote:
> On Thu, Nov 20, 2025 at 10:49:59AM +0100, David Hildenbrand (Red Hat) wrote:
>> On 11/20/25 10:35, Lorenzo Stoakes wrote:
>>> On Thu, Nov 20, 2025 at 10:16:26AM +0100, David Hildenbrand (Red Hat) wrote:
>>>> On 11/20/25 10:04, Lorenzo Stoakes wrote:
>>>>> Hi Vivek, thanks for the patch.
>>>>>
>>>>> In general though, let's please not make a fundamental change to mremap()
>>>>> behaviour in late -rc6. Late in cycle/during merge window we're really only
>>>>> interested in existing series, series that are less involved than this.
>>>>>
>>>>> On Wed, Nov 19, 2025 at 09:35:46PM -0800, Vivek Kasireddy wrote:
>>>>>> When mremap is used to create a new mapping, we should not return
>>>>>> -EFAULT for VMAs with VM_DONTEXPAND or VM_PFNMAP flags set because
>>>>>> the old VMA would neither be expanded nor shrunk in this case. This
>>>>>
>>>>> I guess you're trying to be succinct here and 'clone' each input VMA using
>>>>> the 0 source size input.
>>>>>
>>>>> However this can't work.
>>>>>
>>>>> This operation is not equivalent to an mmap(). It may seem to be for
>>>>> ordinary mappings but in practice it isn't:
>>>>>
>>>>> (syscall)
>>>>> -> do_mremap()
>>>>> -> mremap_at()
>>>>> -> expand_vma()
>>>>> -> move_vma()
>>>>> -> copy_vma_and_data()
>>>>> -> copy_vma()
>>>>>
>>>>> Essentially copying the properties of the VMA to the new region.
>>>>>
>>>>> But this doesn't work for PFN map.
>>>>>
>>>>> At _no point_ are you invoking the original f_op->mmap or
>>>>> f_op->mmap_prepare handler.
>>>>>
>>>>> And these handles for PFN maps set up page tables, because PFN maps
>>>>> literally do not exist as VMAs which have properties independent of their
>>>>> page tables like this.
>>>>
>>>> vfio-pci is a bit different, though, as it uses
>>>> vmf_insert_pfn()/vmf_insert_pfn_pmd()/vmf_insert_pfn_pud() at fault time to
>>>> insert PFNs, not at mmap time using remap_pfn_range() and friends.
>>>>
>>>> (see vfio_pci_mmap_page_fault() )
>>>
>>> It sets VM_DONTEXPAND but is fine with being expanded? :) That sounds like a
>>> bug there:
>>
>> Yeah, I am all confused about expansion. The example code looks like all it
>> wants to do is move a VM_PFNMAP mapping.
>>
>>           if (mremap(iov[i].iov_base, 0, iov[i].iov_len,
>>               MREMAP_FIXED | MREMAP_MAYMOVE, cur) == MAP_FAILED) {
>>               goto err;
>>           }
>>
>> I guess the expansion is because of iov[i].iov_len is bigger than the
>> original VMA?
>>
>> Is that maybe a bug in QEMU or why are we even expanding here?
> 
> We're going from size 0 to iov[i].iov_len, which is saying 'please make a copy
> of this VMA at a new address'.
> 
> There's never any moving, as input size is 0 :)

Ah, so it is indeed cloning. The cloning as part of a "remap" operation 
is really confusing.

> 
> It's a cute corner case way of using mremap().
> 
> We're basically asking for a _copy_. But you can't get a copy of a
> VM_DONTEXPAND/VM_PFNMAP because you need to invoke mmap_prepare (or legacy mmap)
> to get something sensible and you are bypassing that on expansion, even if it's
> a 'clone' style expansion.

Yes, agreed.

As Akihiko writes, what they want to achieve resemble a bit what fork() 
does. But there, the flow is rather different.

-- 
Cheers

David