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: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?

-- 
Cheers

David