linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lstoakes@gmail.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>
Cc: "=Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-fsdevel@vger.kernel.org,
	Lorenzo Stoakes <lstoakes@gmail.com>
Subject: [PATCH v2 0/5]  Abstract vma_merge() and split_vma()
Date: Mon,  9 Oct 2023 21:53:15 +0100	[thread overview]
Message-ID: <cover.1696884493.git.lstoakes@gmail.com> (raw)

The vma_merge() interface is very confusing and its implementation has led
to numerous bugs as a result of that confusion.

In addition there is duplication both in invocation of vma_merge(), but
also in the common mprotect()-style pattern of attempting a merge, then if
this fails, splitting the portion of a VMA about to have its attributes
changed.

This pattern has been copy/pasted around the kernel in each instance where
such an operation has been required, each very slightly modified from the
last to make it even harder to decipher what is going on.

Simplify the whole thing by dividing the actual uses of vma_merge() and
split_vma() into specific and abstracted functions and de-duplicate the
vma_merge()/split_vma() pattern altogether.

Doing so also opens the door to changing how vma_merge() is implemented -
by knowing precisely what cases a caller is invoking rather than having a
central interface where anything might happen we can untangle the brittle
and confusing vma_merge() implementation into something more workable.

For mprotect()-like cases we introduce vma_modify() which performs the
vma_merge()/split_vma() pattern, returning a pointer or an ERR_PTR(err) if
the splits fail.

We provide a number of inline helper functions to make things even clearer:-

* vma_modify_flags()      - Prepare to modify the VMA's flags.
* vma_modify_flags_name() - Prepare to modify the VMA's flags/anon_vma_name
* vma_modify_policy()     - Prepare to modify the VMA's mempolicy.
* vma_modify_flags_uffd() - Prepare to modify the VMA's flags/uffd context.

For cases where a new VMA is attempted to be merged with adjacent VMAs we
add:-

* vma_merge_new_vma() - Prepare to merge a new VMA.
* vma_merge_extend()  - Prepare to extend the end of a new VMA.

v2:
* Correct mistake where error cases would have been treated as success as
  pointed out by Vlastimil.
* Move vma_policy() define to mm_types.h.
* Move anon_vma_name(), anon_vma_name_alloc() and anon_vma_name_free() to
  mm_types.h from mm_inline.h.
* These moves make it possible to implement the vma_modify_*() helpers as
  static inline declarations, so do so.
* Spelling corrections and clarifications.

v1:
https://lore.kernel.org/all/cover.1696795837.git.lstoakes@gmail.com/

Lorenzo Stoakes (5):
  mm: move vma_policy() and anon_vma_name() decls to mm_types.h
  mm: abstract the vma_merge()/split_vma() pattern for mprotect() et al.
  mm: make vma_merge() and split_vma() internal
  mm: abstract merge for new VMAs into vma_merge_new_vma()
  mm: abstract VMA merge and extend into vma_merge_extend() helper

 fs/userfaultfd.c          |  69 ++++++++----------------
 include/linux/mempolicy.h |   4 --
 include/linux/mm.h        |  69 ++++++++++++++++++++----
 include/linux/mm_inline.h |  20 +------
 include/linux/mm_types.h  |  27 ++++++++++
 mm/internal.h             |   7 +++
 mm/madvise.c              |  32 ++++-------
 mm/mempolicy.c            |  22 ++------
 mm/mlock.c                |  27 +++-------
 mm/mmap.c                 | 111 +++++++++++++++++++++++++++++++-------
 mm/mprotect.c             |  35 ++++--------
 mm/mremap.c               |  30 +++++------
 mm/nommu.c                |   4 +-
 13 files changed, 255 insertions(+), 202 deletions(-)

--
2.42.0


             reply	other threads:[~2023-10-09 20:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-09 20:53 Lorenzo Stoakes [this message]
2023-10-09 20:53 ` [PATCH v2 1/5] mm: move vma_policy() and anon_vma_name() decls to mm_types.h Lorenzo Stoakes
2023-10-10  6:46   ` Vlastimil Babka
2023-10-09 20:53 ` [PATCH v2 2/5] mm: abstract the vma_merge()/split_vma() pattern for mprotect() et al Lorenzo Stoakes
2023-10-10  7:12   ` Vlastimil Babka
2023-10-10 18:11     ` Lorenzo Stoakes
2023-10-11  2:14   ` Liam R. Howlett
2023-10-11  6:34     ` Lorenzo Stoakes
2023-10-09 20:53 ` [PATCH v2 3/5] mm: make vma_merge() and split_vma() internal Lorenzo Stoakes
2023-10-09 20:53 ` [PATCH v2 4/5] mm: abstract merge for new VMAs into vma_merge_new_vma() Lorenzo Stoakes
2023-10-11  1:51   ` Liam R. Howlett
2023-10-11  6:48     ` Lorenzo Stoakes
2023-10-09 20:53 ` [PATCH v2 5/5] mm: abstract VMA merge and extend into vma_merge_extend() helper Lorenzo Stoakes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1696884493.git.lstoakes@gmail.com \
    --to=lstoakes@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).