linux-kernel - [PATCH v2 0/7] refactor mremap and fix bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <cover.1741256580.git.lorenzo.stoakes@oracle.com>
Date: Thu,  6 Mar 2025 10:33:56 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Harry Yoo <harry.yoo@...cle.com>, Yosry Ahmed <yosry.ahmed@...ux.dev>
Subject: [PATCH v2 0/7] refactor mremap and fix bug

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.

v2:
* Folded Andrew's fix for move_huge_pud() stub that I missed in v1.
* Folded Andrew's fix for err initialisation in prep_move_vma() that I
  missed in v1.
* Propagated tags (thanks everyone!)
* Aligned comments vertically as per Liam, tidied them up a bit.
* Renamed mremap_operation to mremap_type for consistency.
* Added MREMAP_INVALID as default mremap operation state, and set on
  initialisation as per Liam.
* Renamed 'locked' to 'mlocked' whenever referring to mlock state as per
  Liam.
* Dropped unnecessary vrm_set_remap_type() function as per Liam.
* Corrected redundant comment about iterator invalidation as per Liam.
* Corrected confusing vertical alignment on may_expand_vm() invocation
  as per Liam.

v1:
https://lore.kernel.org/all/cover.1740911247.git.lorenzo.stoakes@oracle.com/

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   | 1445 +++++++++++++++++++++++++++++++++----------------
 3 files changed, 1037 insertions(+), 462 deletions(-)

--
2.48.1