From patchwork Tue Jan 17 10:19:39 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Vlastimil Babka X-Patchwork-Id: 13104455 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 8E9B3C67871 for ; Tue, 17 Jan 2023 10:19:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 864846B0071; Tue, 17 Jan 2023 05:19:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8158C6B0073; Tue, 17 Jan 2023 05:19:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 703386B0074; Tue, 17 Jan 2023 05:19:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 615036B0071 for ; Tue, 17 Jan 2023 05:19:46 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 31C4214061F for ; Tue, 17 Jan 2023 10:19:46 +0000 (UTC) X-FDA: 80363894772.30.BE10123 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf18.hostedemail.com (Postfix) with ESMTP id 638B81C0002 for ; Tue, 17 Jan 2023 10:19:43 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="otgKSDs/"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Sst3FRrT; spf=pass (imf18.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=1673950783; 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: references:dkim-signature; bh=UTVHq9dqZLKTnxoacLYbqbw1DksZEoMSGKP4V1CCGyE=; b=g6ODZmnrwUhLkus35OgczWxZHDSqx8K+KqZyi1DJP3QEw5lmdy48pmP4HK0ITBjNu5IhFK ItDqUG284KHGZP5BMSA5YjHbHVESFblR0rnVFQwM7kClJ1Xz3HyMc5BngGHpepq0/jee+R 4S4QsSH+xvPLXd5U74nuVTI8k2KqtAI= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="otgKSDs/"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Sst3FRrT; spf=pass (imf18.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=1673950783; a=rsa-sha256; cv=none; b=tuImk3U4kj2kw5oh9ucOSMwW7/or8pwRrRPIlZAFPJcYOdMCrpUoSrHqthQoVM6rhwgCVD 7qxpffHLTVMqv576A9SS48vvj2o4yfC3oA5S1q5pMOs15F4lVqhAV/0xprNCFq2cbbAknq 1kpUgAzIyDmJEEOH276zw1VvWs6+Zzc= 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 83A8D38319; Tue, 17 Jan 2023 10:19:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1673950781; 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; bh=UTVHq9dqZLKTnxoacLYbqbw1DksZEoMSGKP4V1CCGyE=; b=otgKSDs/4JpBatRD9Uyk6RUBbfoOxcFlHu2acUs6DQetNtZ/n4o7KQBNf97dA84Wqop5Gx FUh7bLqlED5rcOegRYsHenWz15hsjmEovM8WQa5KXoLfCuJmOQd8YQHU0EQs+lo3g39stP Lyo4lXcZa2nOfpMbDBAE/8oIvE6QNZw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1673950781; 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; bh=UTVHq9dqZLKTnxoacLYbqbw1DksZEoMSGKP4V1CCGyE=; b=Sst3FRrTIY5EJQy/YcXbA4kWi2X6HIK1fMH/lBV6B5b/+R6+/8eF4sLu/pvadiVxhC9GNn u4PH6rwKzK+pluCg== 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 530BA13357; Tue, 17 Jan 2023 10:19:41 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id faB5Ez12xmO+FwAAMHmgww (envelope-from ); Tue, 17 Jan 2023 10:19:41 +0000 From: Vlastimil Babka To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, regressions@leemhuis.info, regressions@lists.linux.dev, Vlastimil Babka , Fabian Vogt , =?utf-8?q?J?= =?utf-8?q?akub_Mat=C4=9Bna?= , stable@vger.kernel.org Subject: [PATCH for 6.1 regression] mm, mremap: fix mremap() expanding for vma's with vm_ops->close() Date: Tue, 17 Jan 2023 11:19:39 +0100 Message-Id: <20230117101939.9753-1-vbabka@suse.cz> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: yup7c4saoma161qreutnr4hjfm7fpfic X-Rspamd-Queue-Id: 638B81C0002 X-HE-Tag: 1673950783-13375 X-HE-Meta: U2FsdGVkX1+cjejIAtEakXAYZ7qD/Ztp+HP6oMf7OodjbokKDM07+/Pcs3/0x3TuOJtLgMe9JyLwtY9gnCPum/rT2ceEHGT1R3Lm3N+JjJqVTWME1BmWcUmZl7wMJc73Pw82no/avHOYrHFtRSWEcvY3xfU5O2iJHIz556eySvM+zsV6b+CEae5VQwcAylfFHlvii3nF9brqkD+SYSLFkabjkFt/3+gYOQnmRfx0vtwysuKvAT+3j8PHQnHBH0dAeCgFRN3PquoZ6Pm0UYixNTE4IXFxai/6XohXxrHuLFtPy60ca3YOw90jyLj0AAddbqyiluZ5i3HwNacncRA/bXiEj+WhXhKsZ7NI4Rt1Ge7fpFtlf+IJgcCmD6hfp1hazGYZ0jJZFIXqpf1ALFdA9VZcc18ePEbaO1MG0Qwmv0oXrxDvBpM2gekLhqbk2bhXrw04+4oXA/RLZF9KckBFY4Q+E2ywcrtw1bKysJ5Z0CWI5dOMKY4D8htS7oAFig/aWJw1DRk7grPbjEayKiOrUWa7vj1NJ/AJWSYNturI059QgrAq3oIMAonT/T5e/R+3ylc3mEbJMEJ6iQGKlJzHQ3Bcf82jMq4l6GpQycLJGhoR4zUorCVtblH3+nzskrd/zRIZoIldiP6/lZ/yQ5DHBTYJ3bn3RZAb/kkDPm/Eyts7G+BC8V9uyUh7r323PROdvlsywjWUM5mcIp58C0Wt0l3BdtN5xwmrzvGBoPbEX2HJcFxsrFygx9ib4AxqFcM8dKdin6lbmbL0b5tW+oznkLXuAIREf6TqaZEBWo/QyNmu6U3KwQexjOmFMMcpUPY74Lc8rFUy7gaoRlH81YFwOVOKqrs8BpEEaiG8qm8OQCJ99zla/RLnsOOpe+KSXd6eN7JAF5QLDsOhfmcqIAnRwsf9HQAn2GM5LcFPrhFpNCcmjncCt55jqdAupua6mKmZrkx6Gqjaudo= 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: Fabian has reported another regression in 6.1 due to ca3d76b0aa80 ("mm: add merging after mremap resize"). The problem is that vma_merge() can fail when vma has a vm_ops->close() method, causing is_mergeable_vma() test to be negative. This was happening for vma mapping a file from fuse-overlayfs, which does have the method. But when we are simply expanding the vma, we never remove it due to the "merge" with the added area, so the test should not prevent the expansion. As a quick fix, check for such vmas and expand them using vma_adjust() directly as was done before commit ca3d76b0aa80. For a more robust long term solution we should try to limit the check for vma_ops->close only to cases that actually result in vma removal, so that no merge would be prevented unnecessarily. Reported-by: Fabian Vogt Link: https://bugzilla.suse.com/show_bug.cgi?id=1206359#c35 Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize") Signed-off-by: Vlastimil Babka Cc: Jakub Matěna Cc: Tested-by: Fabian Vogt --- Thorsten: this should be added to the previous regression which wasn't fully fixed by the previous patch: https://linux-regtracking.leemhuis.info/regzbot/regression/20221216163227.24648-1-vbabka@suse.cz/ mm/mremap.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/mremap.c b/mm/mremap.c index fe587c5d6591..1e234fd95547 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -1032,11 +1032,22 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, * the already existing 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. */ - vma = vma_merge(mm, vma, extension_start, extension_end, + if (!vma->vm_ops || !vma->vm_ops->close) { + vma = vma_merge(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_adjust(vma, vma->vm_start, addr + new_len, + vma->vm_pgoff, NULL)) { + vma = NULL; + } if (!vma) { vm_unacct_memory(pages); ret = -ENOMEM;