The multi-VMA move functionality introduced in commit d23cb648e365
("mm/mremap: permit mremap() move of multiple VMA") doesn't allow moves of
file-backed mappings which specify a custom f_op->get_unmapped_area handler
excepting hugetlb and shmem.

We expand this to include thp_get_unmapped_area to support file-backed
mappings for filesystems which use large folios.

Additionally, when the first VMA in a range is not compatible with a
multi-VMA move, instead of moving the first VMA and returning an error,
this series results in us not moving anything and returning an error
immediately.

Examining this second change in detail:

The semantics of multi-VMA moves in mremap() very clearly indicate that a
failure can result in a partial move of VMAs.

This is in line with other aggregate operations within the kernel, which
share these semantics.

There are two classes of failures we're concerned with - eligiblity for
mutli-VMA move, and transient failures that would occur even if the user
individually moved each VMA.

The latter are either a product of the user using mremap() incorrectly or a
failure due to out-of-memory conditions (which, given the allocations
involved are small, would likely be fatal in any case), or hitting the
mapping limit.

Regardless of the cause, transient issues would be fatal anyway, so it
isn't really material which VMAs succeeded at being moved or not.

However with when it comes to multi-VMA move eligiblity, we face another
issue - we must allow a single VMA to succeed regardless of this eligiblity
(as, of course, it is not a multi-VMA move) - but we must then fail
multi-VMA operations.

The two means by which VMAs may fail the eligbility test are - the VMAs
being UFFD-armed, or the VMA being file-backed and providing its own
f_op->get_unmapped_area() helper (because this may result in MREMAP_FIXED
being disregarded), excepting those known to correctly handle MREMAP_FIXED.

It is therefore conceivable that a user could erroneously try to use this
functionality in these instances, and would prefer to not perform any move
at all should that occur.

This series therefore avoids any move of subsequent VMAs should the first
be multi-VMA move ineligble and the input span exceeds that of the first
VMA.

We also add detailed test logic to assert that multi VMA move with
ineligible VMAs functions as expected.


Andrew - I think this should go in as a hot-fix for 6.17, as it would be
better to change the semantics here before the functionality appears in a
released kernel.

Lorenzo Stoakes (3):
  mm/mremap: allow multi-VMA move when filesystem uses
    thp_get_unmapped_area
  mm/mremap: catch invalid multi VMA moves earlier
  selftests/mm: add test for invalid multi VMA operations

 mm/mremap.c                              |  40 ++--
 tools/testing/selftests/mm/mremap_test.c | 264 ++++++++++++++++++++++-
 2 files changed, 284 insertions(+), 20 deletions(-)

--
2.50.1

On Sun,  3 Aug 2025 12:11:20 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

> Subject: [PATCH 6.17 0/3] mm/mremap: allow multi-VMA move for huge folio, find ineligible earlier

I missed this series until just now, because the Subject: innovation
fooled me.

My pattern recognizer saw "[PATCH 6.17 ..." and said "that's an LTS
patch".  Because that's precisely what they do.  By the million.

I can't say I find this change valuable, really.

Now wondering which other patches I missed.

On Mon, Aug 11, 2025 at 09:01:58PM -0700, Andrew Morton wrote:
> On Sun,  3 Aug 2025 12:11:20 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> > Subject: [PATCH 6.17 0/3] mm/mremap: allow multi-VMA move for huge folio, find ineligible earlier
>
> I missed this series until just now, because the Subject: innovation
> fooled me.
>
> My pattern recognizer saw "[PATCH 6.17 ..." and said "that's an LTS
> patch".  Because that's precisely what they do.  By the million.
>
> I can't say I find this change valuable, really.
>
> Now wondering which other patches I missed.

Yes sorry, just wanted to highlight it as hotfix and it seemed sensible (at the
time)...

On Sun, Aug 03, 2025 at 12:11:20PM +0100, Lorenzo Stoakes wrote:
> The multi-VMA move functionality introduced in commit d23cb648e365
> ("mm/mremap: permit mremap() move of multiple VMA") doesn't allow moves of
> file-backed mappings which specify a custom f_op->get_unmapped_area handler
> excepting hugetlb and shmem.
>
> We expand this to include thp_get_unmapped_area to support file-backed
> mappings for filesystems which use large folios.
>
> Additionally, when the first VMA in a range is not compatible with a
> multi-VMA move, instead of moving the first VMA and returning an error,
> this series results in us not moving anything and returning an error
> immediately.
>
> Examining this second change in detail:
>
> The semantics of multi-VMA moves in mremap() very clearly indicate that a
> failure can result in a partial move of VMAs.
>
> This is in line with other aggregate operations within the kernel, which
> share these semantics.
>
> There are two classes of failures we're concerned with - eligiblity for
> mutli-VMA move, and transient failures that would occur even if the user
> individually moved each VMA.
>
> The latter are either a product of the user using mremap() incorrectly or a
> failure due to out-of-memory conditions (which, given the allocations
> involved are small, would likely be fatal in any case), or hitting the
> mapping limit.

Correction here, it's very confusing to refer to user error as a
'transient' failure (it's not), so replace this sentence with:

The latter is due to out-of-memory conditions (which, given the allocations
involved are small, would likely be fatal in any case), or hitting the
mapping limit.

>
> Regardless of the cause, transient issues would be fatal anyway, so it
> isn't really material which VMAs succeeded at being moved or not.
>
> However with when it comes to multi-VMA move eligiblity, we face another
> issue - we must allow a single VMA to succeed regardless of this eligiblity
> (as, of course, it is not a multi-VMA move) - but we must then fail
> multi-VMA operations.
>
> The two means by which VMAs may fail the eligbility test are - the VMAs
> being UFFD-armed, or the VMA being file-backed and providing its own
> f_op->get_unmapped_area() helper (because this may result in MREMAP_FIXED
> being disregarded), excepting those known to correctly handle MREMAP_FIXED.
>
> It is therefore conceivable that a user could erroneously try to use this
> functionality in these instances, and would prefer to not perform any move
> at all should that occur.
>
> This series therefore avoids any move of subsequent VMAs should the first
> be multi-VMA move ineligble and the input span exceeds that of the first
> VMA.
>
> We also add detailed test logic to assert that multi VMA move with
> ineligible VMAs functions as expected.
>
>
> Andrew - I think this should go in as a hot-fix for 6.17, as it would be
> better to change the semantics here before the functionality appears in a
> released kernel.
>
> Lorenzo Stoakes (3):
>   mm/mremap: allow multi-VMA move when filesystem uses
>     thp_get_unmapped_area
>   mm/mremap: catch invalid multi VMA moves earlier
>   selftests/mm: add test for invalid multi VMA operations
>
>  mm/mremap.c                              |  40 ++--
>  tools/testing/selftests/mm/mremap_test.c | 264 ++++++++++++++++++++++-
>  2 files changed, 284 insertions(+), 20 deletions(-)
>
> --
> 2.50.1

Cheers, Lorenzo