linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@oracle.com>,
	David Hildenbrand <david@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
	Pedro Falcato <pfalcato@suse.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Jeff Xu <jeffxu@chromium.org>
Subject: [PATCH v3 5/5] mm/mseal: rework mseal apply logic
Date: Wed, 16 Jul 2025 18:38:06 +0100	[thread overview]
Message-ID: <9ae70e1c509d790cf174f16e491975efd9be50b6.1752687069.git.lorenzo.stoakes@oracle.com> (raw)
In-Reply-To: <cover.1752687069.git.lorenzo.stoakes@oracle.com>

The logic can be simplified - firstly by renaming the inconsistently named
apply_mm_seal() to mseal_apply().

We then wrap mseal_fixup() into the main loop as the logic is simple enough
to not require it, equally it isn't a hugely pleasant pattern in mprotect()
etc.  so it's not something we want to perpetuate.

We eliminate the need for invoking vma_iter_end() on each loop by directly
determining if the VMA was merged - the only thing we need concern
ourselves with is whether the start/end of the (gapless) range are offset
into VMAs.

This refactoring also avoids the rather horrid 'pass pointer to prev
around' pattern used in mprotect() et al.

No functional change intended.

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Acked-by: David Hildenbrand <david@redhat.com>
---
 mm/mseal.c | 67 ++++++++++++++++--------------------------------------
 1 file changed, 20 insertions(+), 47 deletions(-)

diff --git a/mm/mseal.c b/mm/mseal.c
index 61c07b1369cb..0ab12e09792a 100644
--- a/mm/mseal.c
+++ b/mm/mseal.c
@@ -15,28 +15,6 @@
 #include <linux/sched.h>
 #include "internal.h"
 
-static int mseal_fixup(struct vma_iterator *vmi, struct vm_area_struct *vma,
-		struct vm_area_struct **prev, unsigned long start,
-		unsigned long end, vm_flags_t newflags)
-{
-	int ret = 0;
-	vm_flags_t oldflags = vma->vm_flags;
-
-	if (newflags == oldflags)
-		goto out;
-
-	vma = vma_modify_flags(vmi, *prev, vma, start, end, newflags);
-	if (IS_ERR(vma)) {
-		ret = PTR_ERR(vma);
-		goto out;
-	}
-
-	vm_flags_set(vma, VM_SEALED);
-out:
-	*prev = vma;
-	return ret;
-}
-
 /* Does the [start, end) range contain any unmapped memory? */
 static bool range_contains_unmapped(struct mm_struct *mm,
 		unsigned long start, unsigned long end)
@@ -55,38 +33,33 @@ static bool range_contains_unmapped(struct mm_struct *mm,
 	return prev_end < end;
 }
 
-/*
- * Apply sealing.
- */
-static int apply_mm_seal(unsigned long start, unsigned long end)
+static int mseal_apply(struct mm_struct *mm,
+		unsigned long start, unsigned long end)
 {
-	unsigned long nstart;
 	struct vm_area_struct *vma, *prev;
-	VMA_ITERATOR(vmi, current->mm, start);
+	unsigned long curr_start = start;
+	VMA_ITERATOR(vmi, mm, start);
 
+	/* We know there are no gaps so this will be non-NULL. */
 	vma = vma_iter_load(&vmi);
-	/*
-	 * Note: check_mm_seal should already checked ENOMEM case.
-	 * so vma should not be null, same for the other ENOMEM cases.
-	 */
 	prev = vma_prev(&vmi);
 	if (start > vma->vm_start)
 		prev = vma;
 
-	nstart = start;
 	for_each_vma_range(vmi, vma, end) {
-		int error;
-		unsigned long tmp;
-		vm_flags_t newflags;
-
-		newflags = vma->vm_flags | VM_SEALED;
-		tmp = vma->vm_end;
-		if (tmp > end)
-			tmp = end;
-		error = mseal_fixup(&vmi, vma, &prev, nstart, tmp, newflags);
-		if (error)
-			return error;
-		nstart = vma_iter_end(&vmi);
+		unsigned long curr_end = MIN(vma->vm_end, end);
+
+		if (!(vma->vm_flags & VM_SEALED)) {
+			vma = vma_modify_flags(&vmi, prev, vma,
+					curr_start, curr_end,
+					vma->vm_flags | VM_SEALED);
+			if (IS_ERR(vma))
+				return PTR_ERR(vma);
+			vm_flags_set(vma, VM_SEALED);
+		}
+
+		prev = vma;
+		curr_start = curr_end;
 	}
 
 	return 0;
@@ -185,10 +158,10 @@ int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
 	 * reaching the max supported VMAs, however, those cases shall
 	 * be rare.
 	 */
-	ret = apply_mm_seal(start, end);
+	ret = mseal_apply(mm, start, end);
 
 out:
-	mmap_write_unlock(current->mm);
+	mmap_write_unlock(mm);
 	return ret;
 }
 
-- 
2.50.1



  parent reply	other threads:[~2025-07-16 17:38 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-16 17:38 [PATCH v3 0/5] mseal cleanups, fixup MAP_PRIVATE file-backed case Lorenzo Stoakes
2025-07-16 17:38 ` [PATCH v3 1/5] mm/mseal: always define VM_SEALED Lorenzo Stoakes
2025-07-24 18:34   ` Jeff Xu
2025-07-24 18:44     ` Lorenzo Stoakes
2025-07-16 17:38 ` [PATCH v3 2/5] mm/mseal: update madvise() logic Lorenzo Stoakes
2025-07-24 18:39   ` Jeff Xu
2025-07-24 18:56     ` David Hildenbrand
2025-07-24 22:18       ` David Hildenbrand
2025-07-24 19:07     ` Lorenzo Stoakes
2025-07-24 21:53       ` David Hildenbrand
2025-07-25  6:17         ` Lorenzo Stoakes
2025-07-25 16:22         ` Jeff Xu
2025-07-24 21:15   ` Kees Cook
2025-07-24 21:32     ` David Hildenbrand
2025-07-24 21:41       ` David Hildenbrand
2025-07-24 22:29         ` Kees Cook
2025-07-24 22:47           ` David Hildenbrand
2025-07-25  7:41             ` David Hildenbrand
2025-07-25  5:49     ` Lorenzo Stoakes
2025-07-25 16:21     ` Jeff Xu
2025-07-24 22:12   ` David Hildenbrand
2025-07-25  7:01     ` Lorenzo Stoakes
2025-07-25  7:38       ` David Hildenbrand
2025-07-25  8:53         ` Lorenzo Stoakes
2025-07-25  9:46           ` David Hildenbrand
2025-07-25 10:05             ` Lorenzo Stoakes
2025-07-25 10:10               ` David Hildenbrand
2025-07-25 10:17                 ` Lorenzo Stoakes
2025-07-16 17:38 ` [PATCH v3 3/5] mm/mseal: small cleanups Lorenzo Stoakes
2025-07-24 18:40   ` Jeff Xu
2025-07-16 17:38 ` [PATCH v3 4/5] mm/mseal: Simplify and rename VMA gap check Lorenzo Stoakes
2025-07-24 18:40   ` Jeff Xu
2025-07-25  5:33     ` Lorenzo Stoakes
2025-07-16 17:38 ` Lorenzo Stoakes [this message]
2025-07-24 18:41   ` [PATCH v3 5/5] mm/mseal: rework mseal apply logic Jeff Xu
2025-07-24 18:32 ` [PATCH v3 0/5] mseal cleanups, fixup MAP_PRIVATE file-backed case Jeff Xu
2025-07-24 19:10   ` Lorenzo Stoakes
2025-07-25  6:40 ` 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=9ae70e1c509d790cf174f16e491975efd9be50b6.1752687069.git.lorenzo.stoakes@oracle.com \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=jannh@google.com \
    --cc=jeffxu@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pfalcato@suse.de \
    --cc=vbabka@suse.cz \
    /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