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 4E34AC6FD1F for ; Thu, 16 Mar 2023 08:35:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 98743900004; Thu, 16 Mar 2023 04:35:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9382F900002; Thu, 16 Mar 2023 04:35:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FD73900004; Thu, 16 Mar 2023 04:35:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6E27B900002 for ; Thu, 16 Mar 2023 04:35:44 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 28990ABB85 for ; Thu, 16 Mar 2023 08:35:44 +0000 (UTC) X-FDA: 80574103008.22.E2F34F3 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf19.hostedemail.com (Postfix) with ESMTP id 22CCD1A0018 for ; Thu, 16 Mar 2023 08:35:40 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=hBj89sJn; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="i4zbF/im"; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678955741; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xyh5uGvhV5m2gmbFTSe9oGg9qP1qtpxgm6fUuA7nZJM=; b=SutXvRb5bPPZAXRjpf7TAW6739a8YuriOlLRX1YzNCim3rbuabwNMEERBTRvFNxKUKjYct rLIq0ZgzuOe4Qk2KF3uRlMOa+Ld1i5gbpbnnezTWNZBC9vH/U7Id+/uhQ+DVy63JEtjj6c b02+cqH3YBr+1yF+HD9jXS4H4L9/evc= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=hBj89sJn; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="i4zbF/im"; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678955741; a=rsa-sha256; cv=none; b=cGNbkoJsL6Vjh1+oVJHFgYjkzhNnl9R0EzMdXxHl2q5KclxpSg+0ZJfc3otgHaoy0SL8zI CYq3znDza+H9jX6Xp/+amUPchm0foBNKcNOFTOvYVmttoYeKrxPzYOJs/TINSsSmNjTuns ODfwQqSJowSyZB9hcdTF3lthM576w1M= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 8A80621A38; Thu, 16 Mar 2023 08:35:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1678955739; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xyh5uGvhV5m2gmbFTSe9oGg9qP1qtpxgm6fUuA7nZJM=; b=hBj89sJnEclTOejEPc5hsl5Ym2lIJ1IM2dz8BxbVlRP5cg/ur8GFQni2lmL3Q0Xm7h6/t/ ywIgbPNpBIF8opX0GobOLS/OAkWntf7IYPKoGvHz3Q/Ca8wrAw8R55dSNPe7hf8Rht0VV2 /HAGap/Gr3b/7F7vLeAoLK8TtZOfis8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1678955739; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xyh5uGvhV5m2gmbFTSe9oGg9qP1qtpxgm6fUuA7nZJM=; b=i4zbF/imSwtvq8PhPTuHiiOp4K3JXCeEJA7n0z0TCcgcbdG00qZ8aXM97J/ykM5+tkiUTh Pgij0CG3Q3IfB9BA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 7BE5313A2F; Thu, 16 Mar 2023 08:35:39 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Q+eOHdvUEmSnJQAAMHmgww (envelope-from ); Thu, 16 Mar 2023 08:35:39 +0000 Message-ID: <997d99e4-6ebd-c23e-ca1e-b62155701cb0@suse.cz> Date: Thu, 16 Mar 2023 09:35:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 10/10] mm/mremap: simplify vma expansion again Content-Language: en-US To: Lorenzo Stoakes Cc: Andrew Morton , "Liam R. Howlett" , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev, maple-tree@lists.infradead.org References: <20230309111258.24079-1-vbabka@suse.cz> <20230309111258.24079-11-vbabka@suse.cz> <7a9ca4a6-9713-4e31-9c0f-11ec31817c7a@lucifer.local> From: Vlastimil Babka In-Reply-To: <7a9ca4a6-9713-4e31-9c0f-11ec31817c7a@lucifer.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 22CCD1A0018 X-Rspam-User: X-Stat-Signature: h8cub3bknoi7rd9udd4jsjir31refn9m X-HE-Tag: 1678955740-272953 X-HE-Meta: U2FsdGVkX1+F/7YKonFjhh5s3/fNdjKXWS6oTSNm8Pb+XoFEwxJo9JixWLXKmbjllQ1xOra6Krlw1j002vIUgJkxpa5ydYu3I4smhoThR4PnB7mJeDuPH3p/EOTH7kPt0Q4ZbLAC4rnPki01H0I7KcQGUuRmUaJ4oMCCZTXJieNADiOohv4mzyxC/zB/6v4lJQIS/TMkuXkJNjneBuvkeidqiazXeypkUchyZ52Ih4igAsWFHMaoru634ttdqL4Yt24flsnY7XuXiNCeTvMtG0CrADOK8USEguQ4FD10t3SGkqEBriVSYSJpMomZf1KfZ4DdIpNy0L5+pdjxSIZCt+JO0zPbHUHQi3MU3QYHjyUq0iRfPMdrSluqs8rK2NLIV2GEZfeunh46kCrAjhpPKeJ+fCXABSlwU1zRuErZOnbR5yjYYGuRj9f/qo20wVsV7T07amMKgJSIueP6SafQi7nlr07YZ7qNBL10XIIFc0E8gP7loXAvMsCagfG9lxHRbxoMeexTEj2QmBZuqf033jyLRlG4/L4mdVytRwW+wTlUYHOIuCJwmOvxf2ycMC2UcMCn7GNmC2XnwVQZL6+WwwU3Bd/XOfJhVvSZppjYxw9DwJyKd7FWHEFk6ra7V0yoShE9NkHdpYZqvPF9mFSw4eDTR/xI3GSB/Pq1yHY8LB9MxHi/W2ORXAi5Pw0XxnLpxRGJ/RHD+zyvrqXZhZXYQ4qHZDpqEMqrPFHjsoOUrVmmFYRjq+Cgrd7azipifstUg/+6FI83TejwcRuDNI+T1WpyB6p8QwH3qKcT9QU/YpsEFvX+l70tEpl9UsJkP394+1JdK1CI4E8B+OaZxg8K+QB2t27gMHSqSKx2crHTDaLALb+QmU6MH0Vjvq1lcTDYvVZnCMJOh1eaVgKZ58OU9lEwESK6z9HaULw+3DPKggL6QuEjfyYLeVamyaGy7NfqGfa/3qbxdutUDplpz4u KOzrT2k6 s7Kpodz8fKC2mhdXWbyTzTpZmWuW5XFHiDgQkFneN31n/iGO+Yq2WXGcE5btYi4DBuJeX+M6pKymsYOpq0C5rqRz++esufH0gWHLRMuu+F5VkTZQaPcUSRRjYzBrOvGCuJJArZBQ9aG7g6pDyCFz+GqOz+XvjfKCu0mqMs7mJ5HAIx04Z1wOu2EZqSn/irMbgzplX4hELzj4zTSjgCAWLJCccw0DCHSAjXfL6AnKt1DA2Y0s= 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 3/15/23 23:20, Lorenzo Stoakes wrote: > On Thu, Mar 09, 2023 at 12:12:58PM +0100, Vlastimil Babka wrote: >> This effectively reverts d014cd7c1c35 ("mm, mremap: fix mremap() >> expanding for vma's with vm_ops->close()"). After the recent changes, >> vma_merge() is able to handle the expansion properly even when the vma >> being expanded has a vm_ops->close operation, so we don't need to >> special case it anymore. >> >> Signed-off-by: Vlastimil Babka >> --- >> mm/mremap.c | 20 ++++---------------- >> 1 file changed, 4 insertions(+), 16 deletions(-) >> >> diff --git a/mm/mremap.c b/mm/mremap.c >> index 411a85682b58..65f5b545601e 100644 >> --- a/mm/mremap.c >> +++ b/mm/mremap.c >> @@ -1040,23 +1040,11 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, >> * vma (expand operation itself) and possibly also with >> * the next vma if it becomes adjacent to the expanded >> * vma and otherwise compatible. >> - * >> - * However, vma_merge() can currently fail due to >> - * is_mergeable_vma() check for vm_ops->close (see the >> - * comment there). Yet this should not prevent vma >> - * expanding, so perform a simple expand for such vma. >> - * Ideally the check for close op should be only done >> - * when a vma would be actually removed due to a merge. >> */ >> - if (!vma->vm_ops || !vma->vm_ops->close) { >> - vma = vma_merge(&vmi, mm, vma, extension_start, >> - extension_end, vma->vm_flags, vma->anon_vma, >> - vma->vm_file, extension_pgoff, vma_policy(vma), >> - vma->vm_userfaultfd_ctx, anon_vma_name(vma)); >> - } else if (vma_expand(&vmi, vma, vma->vm_start, >> - addr + new_len, vma->vm_pgoff, NULL)) { >> - vma = NULL; >> - } >> + vma = vma_merge(&vmi, mm, vma, extension_start, >> + extension_end, vma->vm_flags, vma->anon_vma, >> + vma->vm_file, extension_pgoff, vma_policy(vma), >> + vma->vm_userfaultfd_ctx, anon_vma_name(vma)); >> if (!vma) { >> vm_unacct_memory(pages); >> ret = -ENOMEM; >> -- >> 2.39.2 >> > > Good to eliminate this edge case! Do we have a self-test for this case to assert > that the issue is fixed by this? I guess a little tricky due to the need for the > the owning VMA to have ->close() specified. Yeah that's the problem, it needs some specific setup, unlike the existing tests. > In any case, the changes you have made in the previous patch should ensure the > edge case is no longer required, hence:- > > Reviewed-by: Lorenzo Stoakes Thanks!