[0/7] refactor mremap and fix bug

Message

Lorenzo Stoakes March 3, 2025, 11:08 a.m. UTC

The existing mremap() logic has grown organically over a very long period
of time, resulting in code that is in many parts, very difficult to follow
and full of subtleties and sources of confusion.

In addition, it is difficult to thread state through the operation
correctly, as function arguments have expanded, some parameters are
expected to be temporarily altered during the operation, others are
intended to remain static and some can be overridden.

This series completely refactors the mremap implementation, sensibly
separating functions, adding comments to explain the more subtle aspects of
the implementation and making use of small structs to thread state through
everything.

The reason for doing so is to lay the groundwork for planned future changes
to the mremap logic, changes which require the ability to easily pass
around state.

Additionally, it would be unhelpful to add yet more logic to code that is
already difficult to follow without first refactoring it like this.

The first patch in this series additionally fixes a bug when a VMA with
start address zero is partially remapped.

Tested on real hardware under heavy workload and all self tests are
passing.

Lorenzo Stoakes (7):
  mm/mremap: correctly handle partial mremap() of VMA starting at 0
  mm/mremap: refactor mremap() system call implementation
  mm/mremap: introduce and use vma_remap_struct threaded state
  mm/mremap: initial refactor of move_vma()
  mm/mremap: complete refactor of move_vma()
  mm/mremap: refactor move_page_tables(), abstracting state
  mm/mremap: thread state through move page table operation

 mm/internal.h |   49 +-
 mm/mmap.c     |    5 +-
 mm/mremap.c   | 1440 +++++++++++++++++++++++++++++++++----------------
 3 files changed, 1033 insertions(+), 461 deletions(-)

--
2.48.1