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 X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95D91C43464 for ; Thu, 17 Sep 2020 22:47:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D10902311D for ; Thu, 17 Sep 2020 22:47:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D10902311D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3556B6B0037; Thu, 17 Sep 2020 18:47:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 305C66B0055; Thu, 17 Sep 2020 18:47:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 242376B005A; Thu, 17 Sep 2020 18:47:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id 102136B0037 for ; Thu, 17 Sep 2020 18:47:45 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C476A8249980 for ; Thu, 17 Sep 2020 22:47:44 +0000 (UTC) X-FDA: 77274042048.23.cars65_480c69727126 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id A646437604 for ; Thu, 17 Sep 2020 22:47:44 +0000 (UTC) X-HE-Tag: cars65_480c69727126 X-Filterd-Recvd-Size: 3256 Received: from out30-44.freemail.mail.aliyun.com (out30-44.freemail.mail.aliyun.com [115.124.30.44]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Sep 2020 22:47:43 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R501e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04423;MF=richard.weiyang@linux.alibaba.com;NM=1;PH=DS;RN=4;SR=0;TI=SMTPD_---0U9Fg-Aw_1600382859; Received: from localhost(mailfrom:richard.weiyang@linux.alibaba.com fp:SMTPD_---0U9Fg-Aw_1600382859) by smtp.aliyun-inc.com(127.0.0.1); Fri, 18 Sep 2020 06:47:39 +0800 From: Wei Yang To: akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Wei Yang Subject: [PATCH] mm/mmap: do the check on expand instead of on insert Date: Fri, 18 Sep 2020 06:47:22 +0800 Message-Id: <20200917224722.54428-1-richard.weiyang@linux.alibaba.com> X-Mailer: git-send-email 2.20.1 (Apple Git-117) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: 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 necessar= y 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 --- 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 =3D 0; int remove_next =3D 0; =20 - if (next && !insert) { + if (next && expand) { struct vm_area_struct *exporter =3D NULL, *importer =3D NULL; =20 if (end >=3D next->vm_end) { --=20 2.20.1 (Apple Git-117)