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

[Pedro Falcato <pfalcato@suse.de>]

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?

> 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.

-- 
Pedro