All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@linux.alibaba.com>
To: akpm@linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Wei Yang <richard.weiyang@linux.alibaba.com>
Subject: [PATCH] mm/mmap: do the check on expand instead of on insert
Date: Fri, 18 Sep 2020 06:47:22 +0800	[thread overview]
Message-ID: <20200917224722.54428-1-richard.weiyang@linux.alibaba.com> (raw)

Function __vma_adjust() checks on *insert* to decide whether it is
necessary to remove_next/adjust_next. While it is more reasonable to do
the check on *expand* instead of on *insert*, since this is only necessary
when *expand* is non-NULL.

There are several users for __vma_adjust, let's classify them based on
the value of *insert*/*expand*:

   caller                  |    insert/expand
   ------------------------+-----------------
   vma_merge               |    NULL/non-NULL
   __split_vma             |    non-NULL/NULL
   shift_arg_pages/mremap  |    NULL/NULL

To make this change, we need to make sure those non-NULL *insert* cases
wouldn't go into this if branch except vma_merge. There are two cases we
need to take care of: shift_arg_pages and mremap. Let's look at it one
by one.

For mremap, it is for sure we won't go into this if branch since
vma_adjust tries to expand the vma and the vma is expandable(the end
wouldn't interact with vma and next).

For shift_arg_pages, this case is a little tricky. Actually, for this
case, vma->vm_next should be NULL. Otherwise we would go into the branch
of "end < vma->vm_end" since we are shifting left. This means we would
expand the vma->vm_next by accident. Luckily, in current code, we won't
fall into this situation because shift_arg_pages only shift the stack
which is the highest one in virtual space.

To make the code more easy to understand(only vma_merge has a non-NULL
expand), and to make it handle the corner case(shift_arg_pages)
properly, let's do the check on *expand* instead of *insert*.

Signed-off-by: Wei Yang <richard.weiyang@linux.alibaba.com>
---
 mm/mmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 829897646a9c..ca31b405fbfa 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -706,7 +706,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
 	long adjust_next = 0;
 	int remove_next = 0;
 
-	if (next && !insert) {
+	if (next && expand) {
 		struct vm_area_struct *exporter = NULL, *importer = NULL;
 
 		if (end >= next->vm_end) {
-- 
2.20.1 (Apple Git-117)


                 reply	other threads:[~2020-09-17 22:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20200917224722.54428-1-richard.weiyang@linux.alibaba.com \
    --to=richard.weiyang@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.