Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/6] mm/mremap: report a failed split before moving anything
@ 2026-10-30 14:42 Josef Bacik
  2026-10-30 14:42 ` [PATCH 1/6] mm/mremap: fix hugetlb reservation leak on partial move Josef Bacik
                   ` (5 more replies)
  0 siblings, 6 replies; 8+ messages in thread
From: Josef Bacik @ 2026-10-30 14:42 UTC (permalink / raw)
  To: Andrew Morton, Lorenzo Stoakes, Liam R. Howlett,
	David Hildenbrand
  Cc: Vlastimil Babka, Jann Horn, Pedro Falcato, Muchun Song,
	Oscar Salvador, linux-mm, stable, Josef Bacik

Hello,

I went through the callers of __split_vma() to see who can't cope with
it failing, and mremap() is the bad one.  If you move part of a VMA we
don't split it until the very end, when we unmap the old range.  By then
the page tables have moved and there's nothing to go back to, so we fix
up the accounting and return success with the old range still mapped.

Lorenzo recently added a way to split ahead of the move for the mlock()
+ MREMAP_DONTUNMAP case.  This series uses that for every move that
unmaps its source, so a split that fails is reported before we've done
anything.

Doing that turned up a real bug in hugetlb.  We take the reservation map
away from the whole old VMA before the part that's moving is split off,
so the parts that stay never give their reservations back.  That fix is
the first patch so it can go to stable by itself, and the second patch
is a selftest for it.

The next two fix the accounting for when the unmap at the end does fail,
we either charged memory that was never accounted or lost track of the
charge for the whole VMA.  That gets a lot harder to hit with the last
patch but it's still possible.  There's also a test for an old size of
0, which nothing covered.

I tested this with the mm selftests and with a loop that fails each
allocation inside mremap() in turn and checks that we either moved or
didn't.  The numbers for moving part of a mapping don't change.  Thanks,

Josef

---
Josef Bacik (6):
      mm/mremap: fix hugetlb reservation leak on partial move
      selftests/mm: test a partial mremap() of hugetlb memory
      mm/mremap: reaccount on unmap failure only if accounted
      mm/mremap: restore VM_ACCOUNT if the unmap fails
      selftests/mm: test mremap() with an old size of 0
      mm/mremap: split first so a failed split is reported

 mm/mremap.c                                 | 55 +++++++++++++++++++++++------
 tools/testing/selftests/mm/hugetlb-mremap.c | 52 +++++++++++++++++++++++++--
 tools/testing/selftests/mm/mremap_test.c    | 52 ++++++++++++++++++++++++++-
 3 files changed, 145 insertions(+), 14 deletions(-)
---
base-commit: cd1d0b147afa81f80927f9711e53401703964217
change-id: 20261030-b4-mremap-pre-split-13a3d54d6dbd



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-10-31 19:28 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-30 14:42 [PATCH 0/6] mm/mremap: report a failed split before moving anything Josef Bacik
2026-10-30 14:42 ` [PATCH 1/6] mm/mremap: fix hugetlb reservation leak on partial move Josef Bacik
2026-10-30 14:42 ` [PATCH 2/6] selftests/mm: test a partial mremap() of hugetlb memory Josef Bacik
2026-10-30 14:42 ` [PATCH 3/6] mm/mremap: reaccount on unmap failure only if accounted Josef Bacik
2026-10-30 14:42 ` [PATCH 4/6] mm/mremap: restore VM_ACCOUNT if the unmap fails Josef Bacik
2026-10-30 14:42 ` [PATCH 5/6] selftests/mm: test mremap() with an old size of 0 Josef Bacik
2026-10-30 14:42 ` [PATCH 6/6] mm/mremap: split first so a failed split is reported Josef Bacik
2026-10-31 19:27   ` Jose A. Perez de Azpillaga

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox