From: Wei Yang <richard.weiyang@gmail.com>
To: akpm@linux-foundation.org
Cc: linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>,
"Liam R . Howlett" <Liam.Howlett@Oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>
Subject: [PATCH] mm/vma: only set vmg->next when removal is necessary
Date: Mon, 11 Nov 2024 01:23:40 +0000 [thread overview]
Message-ID: <20241111012340.28906-1-richard.weiyang@gmail.com> (raw)
vma_expand() is called by relocate_vma_down() and vma_merge_new_range()
with only vma_merge_new_range() has a chance to remove 'next'.
By leveraging the knowledge in vma_merge_new_range(), only set vmg->next
when removal is necessary, we can simplify the logic in vma_expand().
Originally we have an assumption that VMG state could be safely reused
after a merge. This assumption is removed after commit 5a689bac0bbc
("mm: remove unnecessary reset state logic on merge new VMA"). So we are
safe to clear it.
Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
CC: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
CC: Vlastimil Babka <vbabka@suse.cz>
CC: Jann Horn <jannh@google.com>
---
mm/vma.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/mm/vma.c b/mm/vma.c
index 8a454a7bbc80..85d82bc1eaed 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -984,6 +984,7 @@ struct vm_area_struct *vma_merge_new_range(struct vma_merge_struct *vmg)
can_merge_left = can_vma_merge_left(vmg);
can_merge_right = !just_expand && can_vma_merge_right(vmg, can_merge_left);
+ vmg->next = NULL;
/* If we can merge with the next VMA, adjust vmg accordingly. */
if (can_merge_right) {
vmg->end = next->vm_end;
@@ -1001,8 +1002,12 @@ struct vm_area_struct *vma_merge_new_range(struct vma_merge_struct *vmg)
* are not permitted to do so, reduce the operation to merging
* prev and vma.
*/
- if (can_merge_right && !can_merge_remove_vma(next))
- vmg->end = end;
+ if (can_merge_right) {
+ if (!can_merge_remove_vma(next))
+ vmg->end = end;
+ else
+ vmg->next = next;
+ }
/* In expand-only case we are already positioned at prev. */
if (!just_expand) {
@@ -1030,9 +1035,9 @@ struct vm_area_struct *vma_merge_new_range(struct vma_merge_struct *vmg)
* @vmg: Describes a VMA expansion operation.
*
* Expand @vma to vmg->start and vmg->end. Can expand off the start and end.
- * Will expand over vmg->next if it's different from vmg->vma and vmg->end ==
- * vmg->next->vm_end. Checking if the vmg->vma can expand and merge with
- * vmg->next needs to be handled by the caller.
+ * Will expand over vmg->next if it's set.
+ * Checking if the vmg->vma can expand and merge with vmg->next needs to be
+ * handled by the caller.
*
* Returns: 0 on success.
*
@@ -1043,17 +1048,15 @@ struct vm_area_struct *vma_merge_new_range(struct vma_merge_struct *vmg)
int vma_expand(struct vma_merge_struct *vmg)
{
struct vm_area_struct *anon_dup = NULL;
- bool remove_next = false;
struct vm_area_struct *vma = vmg->vma;
struct vm_area_struct *next = vmg->next;
mmap_assert_write_locked(vmg->mm);
vma_start_write(vma);
- if (next && (vma != next) && (vmg->end == next->vm_end)) {
+ if (next) {
int ret;
- remove_next = true;
/* This should already have been checked by this point. */
VM_WARN_ON(!can_merge_remove_vma(next));
vma_start_write(next);
@@ -1062,13 +1065,10 @@ int vma_expand(struct vma_merge_struct *vmg)
return ret;
}
- /* Not merging but overwriting any part of next is not handled. */
- VM_WARN_ON(next && !remove_next &&
- next != vma && vmg->end > next->vm_start);
/* Only handles expanding */
VM_WARN_ON(vma->vm_start < vmg->start || vma->vm_end > vmg->end);
- if (commit_merge(vmg, NULL, remove_next ? next : NULL, NULL, 0, true))
+ if (commit_merge(vmg, NULL, next, NULL, 0, true))
goto nomem;
return 0;
--
2.34.1
next reply other threads:[~2024-11-11 1:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 1:23 Wei Yang [this message]
2024-11-11 6:42 ` 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=20241111012340.28906-1-richard.weiyang@gmail.com \
--to=richard.weiyang@gmail.com \
--cc=Liam.Howlett@Oracle.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--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