Re: [PATCH 6/6] mm/mremap: split first so a failed split is reported

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

On Fri, Oct 30, 2026 at 02:42:51PM +0000, Josef Bacik wrote:
> mremap() can return the new address although the old range is still mapped,
> which leaves the caller with a VMA it does not know about.

But this is established behaviour and a trade-off, e.g. 'the unmap failed, just
get accounts right' in unmap_source_vma().

So all you're left with is an unexpected MREMAP_DONTUNMAP, basically. And only
when the process is doomed where it doesn't matter.

>
> To move a part of a VMA, that part has to be split off, and this is left to
> the unmap at the end of the move. If the split fails there, the page tables
> have moved already and there is nothing to go back to. unmap_source_vma()
> returns void, so move_vma() reports success.

But it can't fail there as we already did all the checks ahead of time.

>
> This was reproduced with fault injection, by failing each allocation of

Yes, of course :)

> such an mremap() in turn. Anonymous and shmem mappings hit it at 2 to 7 of
> 7 to 13 allocations, with numbers that differ from boot to boot, and no
> longer hit it with this patch.

The only way it can happen in reality is huge memory pressure + a fatal signal +
bad luck on timing.

And at that point the process is going to die anyway, so it doesn't matter.

>
> Fix by splitting the source VMA in prep_move_vma() whenever it is going to
> be unmapped, so that a failed split is reported before anything has moved.

No, this is a big cost for no real-world benefit. Now any kind of failure
results in an unwanted pre-split.

This is more likely to screw people up than rather pointlessly trying to do a
favour for a doomed process.

> An old size of 0 unmaps nothing and does not split. If a later step fails,
> the VMA stays split, as it does after a munmap() that fails half way. The
> unmap at the end can still fail in its allocations, or if copy_vma() has
> merged the range and it has to be split again.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>

So yeah, overall, I don't think we want this patch.

It's not really accomplishing anything that matters in reality, adds a bunch of
complexity and causes pain for normal users.

So please drop this one thanks :)

--
Cheers, Lorenzo