Re: [PATCH] mm/mremap: unmap full fixed target for multi-VMA moves

[Lorenzo Stoakes <ljs@kernel.org>]

On Mon, May 11, 2026 at 05:19:50PM +0200, Jann Horn wrote:
> On Mon, May 11, 2026 at 5:05 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> > On Thu, May 07, 2026 at 06:24:45PM +0000, fujunjie wrote:
> > > When MREMAP_FIXED moves a range spanning multiple VMAs, remap_move()
> > > iterates over the source VMAs and skips source holes.  For each source
> > > VMA segment it narrows vrm->new_len to that segment length before calling
> > > mremap_to(), so the MREMAP_FIXED destination unmap is also limited to the
> > > current segment.
> > >
> > > If the source range contains holes and the destination range is already
> > > mapped, the destination subranges corresponding to those source holes can
> > > therefore survive the move.  That violates MREMAP_FIXED semantics, where
> > > the destination range is supposed to be unmapped before the move, and it
> > > also means that preserved source gaps do not necessarily become gaps in
> > > the destination.  Userspace can then observe mappings at destination
> > > addresses that should have become holes.
> >
> > Hmmm I think it's a bit debateable honestly. The ability to handle there being
> > gaps is a _new thing_, so there are no semantics to speak of. Prevoiusly
> > mremap() simply required that you only span across a single VMA.
>
> FWIW, I think mremap() on a source region with gaps is such a
> hazardous operation that nearly no userspace code should be doing it -
> gaps are areas in which any mmap() call without a fixed address could
> place unrelated mappings (unless stack VMAs are involved, which would
> also be a weird scenario), so to use it safely, you have to, among
> other things, make sure not to use libc malloc() at a time when that
> could place an allocation in the gap (which means you also can't use
> printf(), and so on, unless you have swapped out the memory
> allocator), and make sure that you have no other threads that could be
> doing that, and so on. There are rare circumstances under which it
> could be safe, but I think it is almost always better to have a
> PROT_NONE anonymous VMA or such as a placeholder.

Well, we're holding the mmap write lock so none of that could happen
_during_ the operation right?

You might debate also the fact we hold that for an extended period.

Honestly I probably shouldn't have allowed for this, I've had to do at
least one fixup relating to it I seem to recall and the semantics are
_clearly_ confusing.

>
> I think the right documentation for this is "do not use this on a
> source region with gaps, it is technically possible but extremely
> hazardous".

Yeah, I mean on reflection, allowing it was probably a mistake.

The real use case was 'my VMAs are fragmented and I don't want to have to
know about VMA merge rules in order to move them', i.e. no gaps.

I will do a manpage update and indicate that it probably shouldn't be used
but if it is, the sematics are such that gaps are not propagated (i.e. it
is as if you mremap()'d each individually).

Cheers, Lorenzo