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

["Jose A. Perez de Azpillaga" <azpijr@gmail.com>]

On 10/30/26 3:42 PM, 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.
> 
> 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.
> 
> This was reproduced with fault injection, by failing each allocation of
> 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.
> 
> 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.
> 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.
that later step isn't always an allocation failure though. a partial
mremap() of an aio ring still fails -EINVAL, but now leaves the ring
split in three. is that intended?

-- 
cheers,
jose a. p-a