All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Wandun <chenwandun@huawei.com>
To: <akpm@linux-foundation.org>, <0x7f454c46@gmail.com>,
	<wangkefeng.wang@huawei.com>, <weiyongjun1@huawei.com>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
	Chen Wandun <chenwandun@huawei.com>
Subject: [PATCH] mm/mremap: fix memory account on do_munmap() failure
Date: Sat, 17 Jul 2021 18:19:42 +0800	[thread overview]
Message-ID: <20210717101942.120607-1-chenwandun@huawei.com> (raw)

mremap will account the delta between new_len and old_len in
vma_to_resize, and then call move_vma when expanding an existing
memory mapping. In function move_vma, there are two scenarios when
calling do_munmap:
1. move_page_tables from old_addr to new_addr success
2. move_page_tables from old_addr to new_addr fail

In first scenario, it should account old_len if do_munmap fail,
because the delta has already been accounted.

In second scenario, new_addr/new_len will assign to old_addr/old_len
if move_page_table fail, so do_munmap is try to unmap new_addr actually,
if do_munmap fail, it should account the new_len, because error code
will be return from move_vma, and delta will be unaccounted.
What'more, because of new_len == old_len, so account old_len also is
OK.

In summary, account old_len will be correct if do_munmap fail.

Fixes: 51df7bcb6151 ("mm/mremap: account memory on do_munmap() failure")
Signed-off-by: Chen Wandun <chenwandun@huawei.com>
---
 mm/mremap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/mremap.c b/mm/mremap.c
index 5989d3990020..badfe17ade1f 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -686,7 +686,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
 	if (do_munmap(mm, old_addr, old_len, uf_unmap) < 0) {
 		/* OOM: unable to split vma, just get accounts right */
 		if (vm_flags & VM_ACCOUNT && !(flags & MREMAP_DONTUNMAP))
-			vm_acct_memory(new_len >> PAGE_SHIFT);
+			vm_acct_memory(old_len >> PAGE_SHIFT);
 		excess = 0;
 	}
 
-- 
2.25.1


             reply	other threads:[~2021-07-17 10:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-17 10:19 Chen Wandun [this message]
2021-07-20 23:28 ` [PATCH] mm/mremap: fix memory account on do_munmap() failure Andrew Morton

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=20210717101942.120607-1-chenwandun@huawei.com \
    --to=chenwandun@huawei.com \
    --cc=0x7f454c46@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=wangkefeng.wang@huawei.com \
    --cc=weiyongjun1@huawei.com \
    /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.