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

[Luiz Capitulino]

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.