On Sat, 11 Oct 2025 at 21:20, Matthew Lugg <[email protected]> wrote: > > This typo meant that calls to `mremap` which shrink a mapping by some N > bytes would, when the virtual address space was pre-reserved (e.g. > 32-bit guest on 64-bit host), unmap the N bytes following the *original* > mapping. > > Signed-off-by: Matthew Lugg <[email protected]> > --- > linux-user/mmap.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/linux-user/mmap.c b/linux-user/mmap.c > index 847092a28a..ec8392b35b 100644 > --- a/linux-user/mmap.c > +++ b/linux-user/mmap.c > @@ -1164,7 +1164,8 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong > old_size, > errno = ENOMEM; > host_addr = MAP_FAILED; > } else if (reserved_va && old_size > new_size) { > - mmap_reserve_or_unmap(old_addr + old_size, > + /* Re-reserve pages we just shrunk out of the mapping */ > + mmap_reserve_or_unmap(old_addr + new_size, > old_size - new_size); > } > } > --
Reviewed-by: Peter Maydell <[email protected]> I agree with your cover letter: Cc: [email protected] I think this has been broken for a long time, right back to the introduction of pre-allocated guest address space in commit 68a1c8168, where the code was clearly confused between old_size and new_size: + if (host_addr != MAP_FAILED && reserved_va && old_size > new_size) { + mmap_reserve(old_addr + old_size, new_size - old_size); + } In 2020 commit 257a7e212d5e5 fixed half of this problem (swapping the two sizes in the second argument to mmap_reserve()) but we didn't notice that the first argument was also wrong. thanks -- PMM
