Re: [PATCH 0/6] mm/mremap: report a failed split before moving anything

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Oct 30, 2026 at 02:42:45PM +0000, Josef Bacik wrote:
> Hello,
>
> I went through the callers of __split_vma() to see who can't cope with
> it failing, and mremap() is the bad one.  If you move part of a VMA we

Yeah, what's frustrating there is that, AFAICT, the only really relevant
case is DAX.

But maybe hugetlb somehow raises its ugly head as you allude to.

> don't split it until the very end, when we unmap the old range.  By then
> the page tables have moved and there's nothing to go back to, so we fix
> up the accounting and return success with the old range still mapped.
>
> Lorenzo recently added a way to split ahead of the move for the mlock()
> + MREMAP_DONTUNMAP case.  This series uses that for every move that

MREMAP_DONTUNMAP is another real horror show for bugs. Candidate for
'should have never been merged'...

> unmaps its source, so a split that fails is reported before we've done
> anything.
>
> Doing that turned up a real bug in hugetlb.  We take the reservation map
> away from the whole old VMA before the part that's moving is split off,
> so the parts that stay never give their reservations back.  That fix is
> the first patch so it can go to stable by itself, and the second patch
> is a selftest for it.
>
> The next two fix the accounting for when the unmap at the end does fail,
> we either charged memory that was never accounted or lost track of the
> charge for the whole VMA.  That gets a lot harder to hit with the last
> patch but it's still possible.  There's also a test for an old size of
> 0, which nothing covered.

I feel like the charging logic needs to be reworked anyway. This whole
'drop VMA_ACCOUNT_BIT' hack is extremely stupid.

>
> I tested this with the mm selftests and with a loop that fails each
> allocation inside mremap() in turn and checks that we either moved or
> didn't.  The numbers for moving part of a mapping don't change.  Thanks,
>
> Josef

Anyway, thanks for these, will go through.

>
> ---
> Josef Bacik (6):
>       mm/mremap: fix hugetlb reservation leak on partial move
>       selftests/mm: test a partial mremap() of hugetlb memory
>       mm/mremap: reaccount on unmap failure only if accounted
>       mm/mremap: restore VM_ACCOUNT if the unmap fails
>       selftests/mm: test mremap() with an old size of 0
>       mm/mremap: split first so a failed split is reported
>
>  mm/mremap.c                                 | 55 +++++++++++++++++++++++------
>  tools/testing/selftests/mm/hugetlb-mremap.c | 52 +++++++++++++++++++++++++--
>  tools/testing/selftests/mm/mremap_test.c    | 52 ++++++++++++++++++++++++++-
>  3 files changed, 145 insertions(+), 14 deletions(-)
> ---
> base-commit: cd1d0b147afa81f80927f9711e53401703964217
> change-id: 20261030-b4-mremap-pre-split-13a3d54d6dbd
>

--
Cheers, Lorenzo