[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7b94fcb3-9ffe-1fc8-3f9d-6a7176069aeb@suse.cz>
Date: Wed, 11 Oct 2023 10:35:31 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Lorenzo Stoakes <lstoakes@...il.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>
Cc: "=Liam R . Howlett" <Liam.Howlett@...cle.com>,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v3 2/5] mm: abstract the vma_merge()/split_vma() pattern
for mprotect() et al.
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@...e.cz>
> Signed-off-by: Lorenzo Stoakes <lstoakes@...il.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
Powered by blists - more mailing lists