From: Vlastimil Babka <vbabka@suse.cz>
To: Lorenzo Stoakes <lstoakes@gmail.com>,
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>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v3 2/5] mm: abstract the vma_merge()/split_vma() pattern for mprotect() et al.
Date: Wed, 11 Oct 2023 10:35:31 +0200 [thread overview]
Message-ID: <7b94fcb3-9ffe-1fc8-3f9d-6a7176069aeb@suse.cz> (raw)
In-Reply-To: <b9bf27ff9ac19985f9ce966b83a7dbbe25a31f9d.1696929425.git.lstoakes@gmail.com>
On 10/10/23 20:23, Lorenzo Stoakes wrote:
> mprotect() and other functions which change VMA parameters over a range
> each employ a pattern of:-
>
> 1. Attempt to merge the range with adjacent VMAs.
> 2. If this fails, and the range spans a subset of the VMA, split it
> accordingly.
>
> This is open-coded and duplicated in each case. Also in each case most of
> the parameters passed to vma_merge() remain the same.
>
> Create a new function, vma_modify(), which abstracts this operation,
> accepting only those parameters which can be changed.
>
> To avoid the mess of invoking each function call with unnecessary
> parameters, create inline wrapper functions for each of the modify
> operations, parameterised only by what is required to perform the action.
>
> We can also significantly simplify the logic - by returning the VMA if we
> split (or merged VMA if we do not) we no longer need specific handling for
> merge/split cases in any of the call sites.
>
> Note that the userfaultfd_release() case works even though it does not
> split VMAs - since start is set to vma->vm_start and end is set to
> vma->vm_end, the split logic does not trigger.
>
> In addition, since we calculate pgoff to be equal to vma->vm_pgoff + (start
> - vma->vm_start) >> PAGE_SHIFT, and start - vma->vm_start will be 0 in this
> instance, this invocation will remain unchanged.
>
> We eliminate a VM_WARN_ON() in mprotect_fixup() as this simply asserts that
> vma_merge() correctly ensures that flags remain the same, something that is
> already checked in is_mergeable_vma() and elsewhere, and in any case is not
> specific to mprotect().
>
> Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
> ---
> fs/userfaultfd.c | 71 +++++++++++++---------------------------------
> include/linux/mm.h | 60 +++++++++++++++++++++++++++++++++++++++
> mm/madvise.c | 26 +++--------------
> mm/mempolicy.c | 26 ++---------------
> mm/mlock.c | 25 +++-------------
> mm/mmap.c | 48 +++++++++++++++++++++++++++++++
> mm/mprotect.c | 29 +++----------------
> 7 files changed, 142 insertions(+), 143 deletions(-)
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index a7c6ef764e63..911ab5740a52 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
<snip>
> @@ -1671,26 +1651,13 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx,
> uffd_wp_range(vma, start, vma_end - start, false);
>
> new_flags = vma->vm_flags & ~__VM_UFFD_FLAGS;
> - pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);
> - prev = vma_merge(&vmi, mm, prev, start, vma_end, new_flags,
> - vma->anon_vma, vma->vm_file, pgoff,
> - vma_policy(vma),
> - NULL_VM_UFFD_CTX, anon_vma_name(vma));
> - if (prev) {
> - vma = prev;
> - goto next;
> - }
> - if (vma->vm_start < start) {
> - ret = split_vma(&vmi, vma, start, 1);
> - if (ret)
> - break;
> - }
> - if (vma->vm_end > end) {
> - ret = split_vma(&vmi, vma, end, 0);
> - if (ret)
> - break;
> + vma = vma_modify_flags_uffd(&vmi, prev, vma, start, vma_end,
> + new_flags, NULL_VM_UFFD_CTX);
> + if (IS_ERR(vma)) {
> + ret = PTR_ERR(prev);
This needs to be PTR_ERR(vma)? Probably v2 leftover.
> + break;
> }
> - next:
> +
> /*
> * In the vma_merge() successful mprotect-like case 8:
> * the next vma was merged into the current one and
next prev parent reply other threads:[~2023-10-11 8:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 18:23 [PATCH v3 0/5] Abstract vma_merge() and split_vma() Lorenzo Stoakes
2023-10-10 18:23 ` [PATCH v3 1/5] mm: move vma_policy() and anon_vma_name() decls to mm_types.h Lorenzo Stoakes
2023-10-10 18:23 ` [PATCH v3 2/5] mm: abstract the vma_merge()/split_vma() pattern for mprotect() et al Lorenzo Stoakes
2023-10-11 8:35 ` Vlastimil Babka [this message]
2023-10-10 18:23 ` [PATCH v3 3/5] mm: make vma_merge() and split_vma() internal Lorenzo Stoakes
2023-10-10 18:23 ` [PATCH v3 4/5] mm: abstract merge for new VMAs into vma_merge_new_vma() Lorenzo Stoakes
2023-10-11 6:58 ` Lorenzo Stoakes
2023-10-10 18:23 ` [PATCH v3 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=7b94fcb3-9ffe-1fc8-3f9d-6a7176069aeb@suse.cz \
--to=vbabka@suse.cz \
--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=lstoakes@gmail.com \
--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