From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17848C433EF for ; Sat, 2 Apr 2022 01:52:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 556176B0071; Fri, 1 Apr 2022 21:52:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 505E08D0002; Fri, 1 Apr 2022 21:52:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CD398D0001; Fri, 1 Apr 2022 21:52:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 2C2DF6B0071 for ; Fri, 1 Apr 2022 21:52:42 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E44A36040E for ; Sat, 2 Apr 2022 01:52:31 +0000 (UTC) X-FDA: 79310264502.05.6748D5E Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf05.hostedemail.com (Postfix) with ESMTP id DA4F0100022 for ; Sat, 2 Apr 2022 01:52:30 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KVg3p6x1QzRBsm; Sat, 2 Apr 2022 09:50:46 +0800 (CST) Received: from [10.174.177.76] (10.174.177.76) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sat, 2 Apr 2022 09:52:27 +0800 Subject: Re: [PATCH] mm/mremap: avoid unneeded do_munmap call To: David Hildenbrand , CC: , References: <20220401081023.37080-1-linmiaohe@huawei.com> <3059b709-7d9a-079d-f7c4-f7cda6b7351e@redhat.com> From: Miaohe Lin Message-ID: <18cb65e5-e124-57be-31ed-9ea227c869df@huawei.com> Date: Sat, 2 Apr 2022 09:52:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <3059b709-7d9a-079d-f7c4-f7cda6b7351e@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Stat-Signature: 6k5ham1xchu6tx9c4aqw15tnz3gira9x Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: DA4F0100022 X-HE-Tag: 1648864350-304818 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2022/4/1 18:38, David Hildenbrand wrote: > On 01.04.22 10:10, Miaohe Lin wrote: >> When old_len == new_len, do_munmap will return -EINVAL due to len == 0. >> This errno will be simply ignored because of old_len != new_len check. >> So it is unnecessary to call do_munmap when old_len == new_len because >> nothing is actually done. >> >> Signed-off-by: Miaohe Lin >> --- >> mm/mremap.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/mm/mremap.c b/mm/mremap.c >> index e776d4c2345c..dd966621a056 100644 >> --- a/mm/mremap.c >> +++ b/mm/mremap.c >> @@ -817,9 +817,9 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len, >> goto out; >> } >> >> - if (old_len >= new_len) { >> + if (old_len > new_len) { >> ret = do_munmap(mm, addr+new_len, old_len - new_len, uf_unmap); >> - if (ret && old_len != new_len) >> + if (ret) >> goto out; >> old_len = new_len; >> } > > I remember stumbling over that myself a year ago or so but dig not > deeper. But indeed, both variants (mmu, nommu) return -EINVAL in case > len (old_len - new_len) == 0. > > Maybe that used to be different before ecc1a8993751 ("do_mremap() > untangling, part 2"), but it doesn't look like it. It could be really hard to trace back to the reason. But it's clear that this change does the same thing now and simplifies the code a bit. > > Acked-by: David Hildenbrand Many thanks for your comment and Acked-by tag! Have a nice weekend! :) >