Re: [PATCH 00/10] mm/mremap: permit mremap() move of multiple VMAs

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Sun, Jul 06, 2025 at 11:12:35PM -0700, Hugh Dickins wrote:
> 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.

Thank you that's very kind of you! :) and please, by all means do feel free
to prod or to give your thoughts and opinions on things, they're very
welcome and appreciated!

With respect to this series, I think it really underlines what a difference
refactoring can make to being able to have code do something new - prior to
my last refactoring series and the refactoring bits here I just don't think
it would have been possible.

WRT to the relocate anon series - I thought it'd be interesting to talk
about why it didn't work out a bit in case you/others might find it
interesting:

Indeed, while I'd like us to more efficiently process VMAs in the anon_vma
case, it turns out there's simply too many moving parts for it to be
feasible at this time - I reached the point of dealing with many many edge
cases addressing the points David raised about folios in the swap cache and
migration entries (which might also fail to migrate), having gone to great
lengths to avoid having a not-reliable undo path.

I'd even invented a new means of 'hiding' anon_vma's from the rmap walker,
and did split folio work up front and and and :)

But then there came a point where unavoidably I'd ahave to do a split folio
mid-way through the operation and GUP fast could race and increment a
refcount that'd break that and... it was just obvious this approach wasn't
workable, and was far too fragile.

Important to accept when one reaches such a point, but it wasn't a waste,
as a. there's a lot that can be reused and applied later, b. I learned a
great deal, c. it helped further my research in this area.

I think overall efforts in this direction will require a more ambitious
rework of the anon_vma stuff, something I intend to do :) but it'll all be
done incrementally, with a great deal of care, and obviously working with
the community throughout.

>
> Hugh

Cheers, Lorenzo