Re: [REGRESSION] mremap() fails VMA expansion when VM_MIXEDMAP is set

[Luiz Capitulino <luizcap@redhat.com>]

On 10/23/26 9:00 AM, Pedro Falcato wrote:
> On Fri, Oct 23, 2026 at 08:13:56AM -0400, Luiz Capitulino wrote:
>>
>>
>> On 10/23/26 3:16 AM, Vlastimil Babka (SUSE) wrote:
>>> On 10/23/26 04:31, Luiz Capitulino wrote:
>>>> Growing a VM_MIXEDMAP VMA with mremap(), with or without MREMAP_MAYMOVE, fails
>>>> with -ENOMEM when the address range after the VMA is free.
>>>>
>>>> This regression was introduced in v6.1 by commit ca3d76b0aa80 ("mm: add merging
>>>> after mremap resize"). This commit changed mremap() to use vma_merge() instead
>>>> of vma_adjust() for the expansion case. However, vma_merge() returns NULL for
>>>> a VMA that has any of the VM_SPECIAL flags set.
>>>
>>> Hi,
>>>
>>> 6.1 was a rather long time ago. How was it discovered just now? I.e. what
>>> use case broke by the change and prompted creating the reproducer?
>>
>> The use-case that broke was an application running on an older kernel
>> and accessing a GPFS volume/FS. I was told that GPFS sets VM_MIXEDMAP on
> 
> So the application is growing a file VMA with mremap?

To be honest, I don't know because I don't have access to the
application/production environment that reproduced this. I got a
detailed report with debugging information that allowed me to identify
the regression.

I can try to get this information if it's important for what you're
proposing below.

>> a VMA because it inserts pages in the process address space with
>> vm_insert_page(). I then asked an LLM to check if there was anything in
> 
> FWIW this is really odd for a filesystem to do. I see we have two filesystems
> upstream (at least in 7.3) that do this; that is, cramfs and FUSE DAX. This is
> arguably weird and should be fixed. Perhaps the VM side isn't giving
> filesystems the right flag here.
>