linux-kernel - Re: [PATCH v3 2/5] mm: abstract the vma_merge()/split

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-prev] [day] [month] [year] [list]

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