From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A7F85258 for ; Sat, 12 Jul 2025 22:54:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752360899; cv=none; b=Z/D9HIcw7yAWvUXuajydBulhd3V93KXK7D6fii8XLMdajFDSsvzwIKyXah6cYKwQirRJUlb4TEBEKnHEQSeo2LxX7F5uHQ8ueA1IF94uraTGcDRPZN3xfJgIQImAPjcqulueDIOGfLSra/PjyXcqNxSD6pKpKqiSG0Eh94OenF0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752360899; c=relaxed/simple; bh=5ijy1+WJn3MlFO8AdXRLL1y956RhMf01aPG6lZP/P6c=; h=Date:To:From:Subject:Message-Id; b=pxfLqK62p9wH1gU1kgKX36rMG6gl7dCRjtZFGntZJCvyWi44cF9ntFoh+EA8FjWb+mT9tspmmtDoGwnmn+bQ09ENBSR0QhfRS51h/0bAReVr0Gh/KG8AlSgmdn2LEY/1P9YRwYeV9LTFeIzcExPbhf+9hJgMF6H8bazmUcPktYQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=s8/w0ISB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="s8/w0ISB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9958C4CEEF; Sat, 12 Jul 2025 22:54:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1752360899; bh=5ijy1+WJn3MlFO8AdXRLL1y956RhMf01aPG6lZP/P6c=; h=Date:To:From:Subject:From; b=s8/w0ISB/blAtNH6z/W3+1PclPXrNTnlWBEGGTwaNxOaoIH1mb7rRZb8kREgGhbhs 0XZF1Dd4JOnKv2A2wxqk+XnOApsaqWGI+iCpresPqC0Zfd1QUwF/sTU6JZr30HmtyR u9KMytymV/mX69BJcFU7FbVdHbb+qMFHhyyCVyJE= Date: Sat, 12 Jul 2025 15:54:58 -0700 To: mm-commits@vger.kernel.org,viro@zeniv.linux.org.uk,vbabka@suse.cz,riel@surriel.com,peterx@redhat.com,liam.howlett@oracle.com,jannh@google.com,jack@suse.cz,brauner@kernel.org,lorenzo.stoakes@oracle.com,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-mremap-put-vma-check-and-prep-logic-into-helper-function.patch added to mm-unstable branch Message-Id: <20250712225458.E9958C4CEEF@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: mm/mremap: put VMA check and prep logic into helper function has been added to the -mm mm-unstable branch. Its filename is mm-mremap-put-vma-check-and-prep-logic-into-helper-function.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-mremap-put-vma-check-and-prep-logic-into-helper-function.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Lorenzo Stoakes Subject: mm/mremap: put VMA check and prep logic into helper function Date: Fri, 11 Jul 2025 12:38:17 +0100 Rather than lumping everything together in do_mremap(), add a new helper function, check_prep_vma(), to do the work relating to each VMA. This further lays groundwork for subsequent patches which will allow for batched VMA mremap(). Additionally, if we set vrm->new_addr == vrm->addr when prepping the VMA, this avoids us needing to do so in the expand VMA mlocked case. No functional change intended. Link: https://lkml.kernel.org/r/b63a058aa748af435db933e1e9c8fea945fe604c.1752232673.git.lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes Reviewed-by: Vlastimil Babka Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Cc: Jann Horn Cc: Liam Howlett Cc: Peter Xu Cc: Rik van Riel Signed-off-by: Andrew Morton --- mm/mremap.c | 58 ++++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 30 deletions(-) --- a/mm/mremap.c~mm-mremap-put-vma-check-and-prep-logic-into-helper-function +++ a/mm/mremap.c @@ -1634,7 +1634,6 @@ static bool align_hugetlb(struct vma_rem static unsigned long expand_vma(struct vma_remap_struct *vrm) { unsigned long err; - unsigned long addr = vrm->addr; err = remap_is_valid(vrm); if (err) @@ -1649,16 +1648,8 @@ static unsigned long expand_vma(struct v if (err) return err; - /* - * We want to populate the newly expanded portion of the VMA to - * satisfy the expectation that mlock()'ing a VMA maintains all - * of its pages in memory. - */ - if (vrm->mlocked) - vrm->new_addr = addr; - /* OK we're done! */ - return addr; + return vrm->addr; } /* @@ -1714,10 +1705,33 @@ static unsigned long mremap_at(struct vm return -EINVAL; } +static int check_prep_vma(struct vma_remap_struct *vrm) +{ + struct vm_area_struct *vma = vrm->vma; + + if (!vma) + return -EFAULT; + + /* If mseal()'d, mremap() is prohibited. */ + if (!can_modify_vma(vma)) + return -EPERM; + + /* Align to hugetlb page size, if required. */ + if (is_vm_hugetlb_page(vma) && !align_hugetlb(vrm)) + return -EINVAL; + + vrm_set_delta(vrm); + vrm->remap_type = vrm_remap_type(vrm); + /* For convenience, we set new_addr even if VMA won't move. */ + if (!vrm_implies_new_addr(vrm)) + vrm->new_addr = vrm->addr; + + return 0; +} + static unsigned long do_mremap(struct vma_remap_struct *vrm) { struct mm_struct *mm = current->mm; - struct vm_area_struct *vma; unsigned long res; vrm->old_len = PAGE_ALIGN(vrm->old_len); @@ -1731,26 +1745,10 @@ static unsigned long do_mremap(struct vm return -EINTR; vrm->mmap_locked = true; - vma = vrm->vma = vma_lookup(mm, vrm->addr); - if (!vma) { - res = -EFAULT; - goto out; - } - - /* If mseal()'d, mremap() is prohibited. */ - if (!can_modify_vma(vma)) { - res = -EPERM; - goto out; - } - - /* Align to hugetlb page size, if required. */ - if (is_vm_hugetlb_page(vma) && !align_hugetlb(vrm)) { - res = -EINVAL; + vrm->vma = vma_lookup(current->mm, vrm->addr); + res = check_prep_vma(vrm); + if (res) goto out; - } - - vrm_set_delta(vrm); - vrm->remap_type = vrm_remap_type(vrm); /* Actually execute mremap. */ res = vrm_implies_new_addr(vrm) ? mremap_to(vrm) : mremap_at(vrm); _ Patches currently in -mm which might be from lorenzo.stoakes@oracle.com are mm-madvise-remove-the-visitor-pattern-and-thread-anon_vma-state.patch mm-madvise-thread-mm_struct-through-madvise_behavior.patch mm-madvise-thread-vma-range-state-through-madvise_behavior.patch mm-madvise-thread-all-madvise-state-through-madv_behavior.patch mm-madvise-eliminate-very-confusing-manipulation-of-prev-vma.patch mm-madvise-eliminate-very-confusing-manipulation-of-prev-vma-fix.patch tools-testing-selftests-add-mremap-unfaulted-faulted-test-cases.patch mm-mremap-perform-some-simple-cleanups.patch mm-mremap-refactor-initial-parameter-sanity-checks.patch mm-mremap-put-vma-check-and-prep-logic-into-helper-function.patch mm-mremap-cleanup-post-processing-stage-of-mremap.patch mm-mremap-use-an-explicit-uffd-failure-path-for-mremap.patch mm-mremap-check-remap-conditions-earlier.patch mm-mremap-move-remap_is_valid-into-check_prep_vma.patch mm-mremap-clean-up-mlock-populate-behaviour.patch mm-mremap-permit-mremap-move-of-multiple-vmas.patch mm-mremap-permit-mremap-move-of-multiple-vmas-fix.patch tools-testing-selftests-extend-mremap_test-to-test-multi-vma-mremap.patch