From: Pedro Falcato <pedro.falcato@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
oliver.sang@intel.com, torvalds@linux-foundation.org,
jeffxu@google.com, Michael Ellerman <mpe@ellerman.id.au>,
Pedro Falcato <pedro.falcato@gmail.com>
Subject: [PATCH 4/7] mm/mremap: Replace can_modify_mm with can_modify_vma
Date: Tue, 6 Aug 2024 22:28:05 +0100 [thread overview]
Message-ID: <20240806212808.1885309-5-pedro.falcato@gmail.com> (raw)
In-Reply-To: <20240806212808.1885309-1-pedro.falcato@gmail.com>
Delegate all can_modify checks to the proper places. Unmap checks are
done in do_unmap (et al).
This patch allows for mremap partial failure in certain cases (for
instance, when destination VMAs aren't sealed, but the source VMA is).
It shouldn't be too troublesome, as you'd need to go out of your way to
do illegal operations on a VMA.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
---
mm/mremap.c | 33 +++++++--------------------------
1 file changed, 7 insertions(+), 26 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index e7ae140fc64..8af877d7bb0 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -676,6 +676,9 @@ static unsigned long move_vma(struct vm_area_struct *vma,
if (unlikely(flags & MREMAP_DONTUNMAP))
to_account = new_len;
+ if (!can_modify_vma(vma))
+ return -EPERM;
+
if (vma->vm_ops && vma->vm_ops->may_split) {
if (vma->vm_start != old_addr)
err = vma->vm_ops->may_split(vma, old_addr);
@@ -821,6 +824,10 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
if (!vma)
return ERR_PTR(-EFAULT);
+ /* Don't allow vma expansion when it has already been sealed */
+ if (!can_modify_vma(vma))
+ return ERR_PTR(-EPERM);
+
/*
* !old_len is a special case where an attempt is made to 'duplicate'
* a mapping. This makes no sense for private mappings as it will
@@ -902,19 +909,6 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
if ((mm->map_count + 2) >= sysctl_max_map_count - 3)
return -ENOMEM;
- /*
- * In mremap_to().
- * Move a VMA to another location, check if src addr is sealed.
- *
- * Place can_modify_mm here because mremap_to()
- * does its own checking for address range, and we only
- * check the sealing after passing those checks.
- *
- * can_modify_mm assumes we have acquired the lock on MM.
- */
- if (unlikely(!can_modify_mm(mm, addr, addr + old_len)))
- return -EPERM;
-
if (flags & MREMAP_FIXED) {
/*
* In mremap_to().
@@ -1079,19 +1073,6 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
goto out;
}
- /*
- * Below is shrink/expand case (not mremap_to())
- * Check if src address is sealed, if so, reject.
- * In other words, prevent shrinking or expanding a sealed VMA.
- *
- * Place can_modify_mm here so we can keep the logic related to
- * shrink/expand together.
- */
- if (unlikely(!can_modify_mm(mm, addr, addr + old_len))) {
- ret = -EPERM;
- goto out;
- }
-
/*
* Always allow a shrinking remap: that just unmaps
* the unnecessary pages..
--
2.46.0
next prev parent reply other threads:[~2024-08-06 21:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-06 21:28 [PATCH 0/7] mm: Optimize mseal checks Pedro Falcato
2024-08-06 21:28 ` [PATCH 1/7] mm: Move can_modify_vma to mm/internal.h Pedro Falcato
2024-08-06 21:28 ` [PATCH 2/7] mm/munmap: Replace can_modify_mm with can_modify_vma Pedro Falcato
2024-08-07 13:02 ` Lorenzo Stoakes
2024-08-07 13:13 ` Pedro Falcato
2024-08-06 21:28 ` [PATCH 3/7] mm/mprotect: " Pedro Falcato
2024-08-06 21:28 ` Pedro Falcato [this message]
2024-08-06 23:09 ` [PATCH 4/7] mm/mremap: " Jeff Xu
2024-08-07 0:59 ` Pedro Falcato
2024-08-07 1:47 ` Jeff Xu
2024-08-06 21:28 ` [PATCH 5/7] mseal: Fix is_madv_discard() Pedro Falcato
2024-08-07 13:13 ` Lorenzo Stoakes
2024-08-06 21:28 ` [PATCH 6/7] mseal: Replace can_modify_mm_madv with a vma variant Pedro Falcato
2024-08-06 21:28 ` [PATCH 7/7] mm: Remove can_modify_mm() Pedro Falcato
2024-08-06 22:24 ` [PATCH 0/7] mm: Optimize mseal checks Jeff Xu
2024-08-07 0:49 ` Pedro Falcato
2024-08-07 1:39 ` Jeff Xu
2024-08-07 12:56 ` Pedro Falcato
2024-08-07 14:15 ` Jeff Xu
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=20240806212808.1885309-5-pedro.falcato@gmail.com \
--to=pedro.falcato@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=jeffxu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mpe@ellerman.id.au \
--cc=oliver.sang@intel.com \
--cc=torvalds@linux-foundation.org \
--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
all inboxes | Powered by JetHome®