On Mon, 7 Jul 2025, Lorenzo Stoakes wrote: > Historically we've made it a uAPI requirement that mremap() may only > operate on a single VMA at a time. > > For instances where VMAs need to be resized, this makes sense, as it > becomes very difficult to determine what a user actually wants should they > indicate a desire to expand or shrink the size of multiple VMAs (truncate? > Adjust sizes individually? Some other strategy?). > > However, in instances where a user is moving VMAs, it is restrictive to > disallow this. > > This is especially the case when anonymous mapping remap may or may not be > mergeable depending on whether VMAs have or have not been faulted due to > anon_vma assignment and folio index alignment with vma->vm_pgoff. > > Often this can result in surprising impact where a moved region is faulted, > then moved back and a user fails to observe a merge from otherwise > compatible, adjacent VMAs. > > This change allows such cases to work without the user having to be > cognizant of whether a prior mremap() move or other VMA operations has > resulted in VMA fragmentation. > > In order to do this, this series performs a large amount of refactoring, > most pertinently - grouping sanity checks together, separately those that > check input parameters and those relating to VMAs. > > we also simplify the post-mmap lock drop processing for uffd and mlock()'d > VMAs. > > With this done, we can then fairly straightforwardly implement this > functionality. > > This works exclusively for mremap() invocations which specify > MREMAP_FIXED. It is not compatible with VMAs which use userfaultfd, as the > notification of the userland fault handler would require us to drop the > mmap lock. > > The input and output addresses ranges must not overlap. We carefully > account for moves which would result in VMA merges or would otherwise > result in VMA iterator invalidation. Applause! No way shall I review this, but each time I've seen an mremap series from Lorenzo go by, I've wanted to say "but wouldn't it be better to..."; but it felt too impertinent to prod you in a direction I'd never dare take myself (and quite likely that you had already tried, but found it fundamentally impossible). Thank you, yes, this is a very welcome step forward. Hugh
