Re: [PATCH 0/2] mm/mremap: fix two issues with MREMAP_DONTUNMAP

From: Anirudh Srinivasan

Date: Wed Sep 30 2026 - 16:14:15 EST

On Sun, Sep 20, 2026 at 03:13:09PM +0100, Lorenzo Stoakes (ARM) wrote:
> The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap()
> operations that keep the original VMA in place.
>
> Historically this has led to a lot of bugs where non-obvious interactions
> occur between existing mremap() operations and the original VMA.
>
> Commit 397432cab17b ("mm/mremap: account mm->locked_vm correctly for
> MREMAP_DONTUNMAP") fixed an accidentally introduced bug around
> mm->locked_vm accounting, but this wasn't the only issue.
>
> And thus history repeats itself, as it turns out that mm->locked_vm
> accounting is broken by MREMAP_DONTUNMAP yet again by two further cases,
> and has been broken ever since the feature was introduced.
>
> Both relate to the fact that VMA_LOCKED_BIT is cleared on the source
> VMA (it has to be as all page tables are moved):
>
> 1. If an unfaulted VMA_LOCKONFAULT_BIT anonymous VMA self-merges it
> clears the VMA_LOCKED_BIT flag and permanently leaks mm->locked_vm
> pages.
>
> 2. If a partial mremap() is performed on a locked VMA there is a leak equal
> to the number of pages not copied.
>
> (Both for MREMAP_DONTUNMAP operations only)
>
> Both issues can be fixed by treating the source range as distinct from the
> destination range, which is the definition of what MREMAP_DONTUNMAP does so
> is appropriate.
>
> In case 1, simply disallow the self-merge, keeping adjacent source and
> destination VMAs distinct.
>
> In case 2, split the source range ahead of time, so accounting is always
> correct.
>
> Both changes were tested locally and confirmed to fix the issues.
>
> For the purposes of a backport, the fixes are kept distinct, a follow-up
> series can add self-tests.
>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> ---
> Lorenzo Stoakes (ARM) (2):
> mm/mremap: fix locked_vm leak from MREMAP_DONTUNMAP self-merge
> mm/mremap: fix locked_vm leak by splitting VMA for MREMAP_DONTUNMAP

Hello,

Apologies for the double mail. I did not hit reply all first time.

I am seeing some failures in the proc_maps_race kselftests after
this patch was added to linux-next. The failures are in
test_maps_tearing_from_remap and test_maps_tearing_from_resize. I have
attached some logs below

# # RUN proc_maps_race.maps.test_maps_tearing_from_remap ...
# ==== Tearing from remap ====
# Before modification
# 3fb317e000-3fb3181000 r--p 00000000 00:00 0
# 3fb3181000-3fb3184000 rw-p 00000000 00:00 0
# 3fb3184000-3fb3187000 r--p 00000000 00:00 0
# -----------------page boundary-----------------
# 3fb3187000-3fb318a000 rw-p 00000000 00:00 0
# 3fb318a000-3fb318d000 r--p 00000000 00:00 0
# 3fb318d000-3fb3190000 rw-p 00000000 00:00 0
#
# After modification
# 3fb317e000-3fb3181000 r--p 00000000 00:00 0
# 3fb3181000-3fb3184000 rw-p 00000000 00:00 0
# 3fb3184000-3fb3185000 r--p 00000000 00:00 0
# -----------------page boundary-----------------
# 3fb3185000-3fb3186000 rw-p 00000000 00:00 0
# 3fb3186000-3fb3187000 r--p 00000000 00:00 0
# 3fb3187000-3fb3189000 rw-p 00000000 00:00 0
#
# After restore
# 3fb317e000-3fb3181000 r--p 00000000 00:00 0
# 3fb3181000-3fb3184000 rw-p 00000000 00:00 0
# 3fb3184000-3fb3187000 r--p 00000000 00:00 0
# -----------------page boundary-----------------
# 3fb3187000-3fb3189000 rw-p 00000000 00:00 0
# 3fb3189000-3fb318a000 rw-p 00000000 00:00 0
# 3fb318a000-3fb318d000 r--p 00000000 00:00 0
#
# # proc-maps-race.c:1081:test_maps_tearing_from_remap:Expected 0 (0) != capture_mod_pattern(self, &remapped_last_line, &remapped_first_line, &restored_last_line, &restored_first_line) (0)
# # test_maps_tearing_from_remap: Test terminated by timeout
# # FAIL proc_maps_race.maps.test_maps_tearing_from_remap
# not ok 3 proc_maps_race.maps.test_maps_tearing_from_remap

# # RUN proc_maps_race.smaps.test_maps_tearing_from_resize ...
# ==== Tearing from resize ====
# Before modificationB
# Locked: 0 kB
# THPeligible: 0
# VmFlags: rd wr mr mw me ac
# -----------------page boundary-----------------
# 3fb30a0000-3fb30a3000 r--p 00000000 00:00 0
# Size: 12 kB
# KernelPageSize: 4 kB
#
# After modificationB
# Locked: 0 kB
# THPeligible: 0
# VmFlags: rd wr mr mw me ac
# -----------------page boundary-----------------
# 3fb30a0000-3fb30a3000 r--p 00000000 00:00 0
# Size: 12 kB
# KernelPageSize: 4 kB
#
# After restoreB
# Locked: 0 kB
# THPeligible: 0
# VmFlags: rd wr mr mw me ac
# -----------------page boundary-----------------
# 3fb30a0000-3fb30a3000 r--p 00000000 00:00 0
# Size: 12 kB
# KernelPageSize: 4 kB
#
# Expected stats: Rss 808 kB
# Pss 86 kB
# Pss_Dirty 51 kB
# Pss_Anon 48 kB
# Pss_File 34 kB
# Pss_Shmem 3 kB
# Shared_Clean 696 kB
# Shared_Dirty 84 kB
# Private_Clean 0 kB
# Private_Dirty 28 kB
# Referenced 760 kB
# Anonymous 104 kB
# KSM 0 kB
# LazyFree 0 kB
# AnonHugePages 0 kB
# ShmemPmdMapped 0 kB
# FilePmdMapped 0 kB
# Shared_Hugetlb 0 kB
# Private_Hugetlb 0 kB
# Swap 0 kB
# SwapPss 0 kB
# Locked 0 kB
# Actual stats: Rss 808 kB
# Pss 98 kB
# Pss_Dirty 59 kB
# Pss_Anon 56 kB
# Pss_File 38 kB
# Pss_Shmem 3 kB
# Shared_Clean 696 kB
# Shared_Dirty 84 kB
# Private_Clean 0 kB
# Private_Dirty 28 kB
# Referenced 756 kB
# Anonymous 104 kB
# KSM 0 kB
# LazyFree 0 kB
# AnonHugePages 0 kB
# ShmemPmdMapped 0 kB
# FilePmdMapped 0 kB
# Shared_Hugetlb 0 kB
# Private_Hugetlb 0 kB
# Swap 0 kB
# SwapPss 0 kB
# Locked 0 kB
# # proc-maps-race.c:1050:test_maps_tearing_from_resize:Expected 0 (0) != compare_smaps_rollup(self, &orig_stats, &stats) (0)

I'm not sure if this is inteded or the tests need updating.

While running this selftest in LAVA, there seems to be another issue
where the 30 second test timeout doesn't seem to work properly. It
appears as thought the test has hung. I am still looking into this. This
issue doesn't seem to happen while running the test from a shell. It is
probably something to do with how LAVA runs the test.

Regards
Anirudh Srinivasan

>
> mm/mremap.c | 87 +++++++++++++++++++++++++++----------------
> mm/vma.c | 19 +++++++++-
> mm/vma.h | 7 +++-
> tools/testing/vma/tests/vma.c | 10 ++---
> 4 files changed, 83 insertions(+), 40 deletions(-)
> ---
> base-commit: a3d0117e02bfa1c3bb6c50e7afe42bbecdbb3459
> change-id: 20260920-fix-dontunmap-partial-self-merge-74a98b1d5a65
>
> Best regards,
> --
> Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
>