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 AE2E2C00A5A for ; Thu, 19 Jan 2023 13:37:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F3096B0072; Thu, 19 Jan 2023 08:37:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A3286B0073; Thu, 19 Jan 2023 08:37:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B9D06B0074; Thu, 19 Jan 2023 08:37:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EFBB16B0072 for ; Thu, 19 Jan 2023 08:37:31 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CA19414075F for ; Thu, 19 Jan 2023 13:37:31 +0000 (UTC) X-FDA: 80371650702.14.DE69341 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [80.237.130.52]) by imf03.hostedemail.com (Postfix) with ESMTP id F350C2000F for ; Thu, 19 Jan 2023 13:37:28 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of regressions@leemhuis.info designates 80.237.130.52 as permitted sender) smtp.mailfrom=regressions@leemhuis.info; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674135449; h=from:from:sender:reply-to: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; bh=jmyCRczcn05BJZTojSzAMUACHP445UW52mnic6wD0ZQ=; b=nabdXIlCWSEDJYukxGN4TWcZgmZ9pSXGLWlIaN6nC63x2U0NDySQLQURmsDTLxsWNNlUg2 DYqWwHtyuTmKe0+3v55ug0PcTK/WPLA5XeNBUmJ1eiS9HKHbat9TKGkySwxjpeEHLgsUVn bASp4vJyxdIH7eqihYlPmi/oBoQnYuM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of regressions@leemhuis.info designates 80.237.130.52 as permitted sender) smtp.mailfrom=regressions@leemhuis.info; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674135449; a=rsa-sha256; cv=none; b=DraEcond/Dymi6nG9G/VAW9LhjtmJO5NkJJz7qLkbAmgrOM/C6LwMDT5PWLpui+cetKwc9 yT0UvtCvxhGobWcC1xn8yLYKxvmYrap9DqlMEGqcu1uhOOI3rYyOtdXuWO19WivLgFAyz5 ADkri5eRhRab26BMNAPIYgQtBJEyFY4= Received: from [2a02:8108:963f:de38:4bc7:2566:28bd:b73c]; authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1pIV6d-0005xG-34; Thu, 19 Jan 2023 14:37:27 +0100 Message-ID: <2f03bd25-bfa1-a8fe-558e-ae3ce22b97fa@leemhuis.info> Date: Thu, 19 Jan 2023 14:37:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Reply-To: Linux regressions mailing list Subject: Re: [PATCH for 6.1 regression] mm, mremap: fix mremap() expanding for vma's with vm_ops->close() Content-Language: en-US, de-DE To: Vlastimil Babka , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, regressions@lists.linux.dev, Fabian Vogt , =?UTF-8?Q?Jakub_Mat=c4=9bna?= , stable@vger.kernel.org References: <20230117101939.9753-1-vbabka@suse.cz> From: "Linux kernel regression tracking (Thorsten Leemhuis)" In-Reply-To: <20230117101939.9753-1-vbabka@suse.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de;regressions@leemhuis.info;1674135449;23863f40; X-HE-SMSGID: 1pIV6d-0005xG-34 X-Stat-Signature: rq3khfcgs6917jymnthx8j1bphyp8qpt X-Rspam-User: X-Rspamd-Queue-Id: F350C2000F X-Rspamd-Server: rspam06 X-HE-Tag: 1674135448-713265 X-HE-Meta: U2FsdGVkX1+m4jJdxirwpQ8DrhP480w7oGHu1zAJVvbQbiEGHeF8FSgE8swuE8yAfcx4RGPTdmhqlCo0w4XJV2kGBkV+EBgH/wdyPsVEeqZad30sfmCH0mQ+Uug4TPWNoaydj2zH/4zt8Ckt5cCmJDOF2K9gZpXYriiN9gBkMBvtEOoIMVKi9YijaHmQQU6N/B8CxSdvzEW9v71UUEQ0pkpTP7b0P1D3N0M/1308auvNdgZQNY2SiNJQISUfV4T6gYLy898PcWRW5JFbicZW8LFmJGN8AGrOVSi51MOCYeekam/+cBQs6P+M97IKYWrzCts1YtC/yJEa5AzNqXfVqA8bkDJuIBPjCfGroBFSp9BmFTB5bIz/3+HAyAUvCYVu4xL7BjWhSGrDiLwdZI6dr1693I3abr+cPBPcAtRfomW+1zIMLoCIofDyOdfXl1cIKDA6nMoVtd8GKu+kBO9swgCLlNJQz63fRFxvLoYs69kSQ6c8s74XMgchqDTEWV/LXjya5xJ7lyAsmh+TLeZNyeDVBEVRev9VFD3ApPdD+zb4zGD6jTfK2gl6jt3WNzy4803UCpzCmnSTeOuMeXPgDZjcsDOicu2jWZuMEjq6k5Jun2q2b1bcas/3taMIke02sg/p+6qHRZlFpstA588JkDZUGIRgAl7fbMzrYVNBAz3WcjiteZSuC8DzNzRj7jLWxQ1hoVLKM+xSyYMf9QYkUogIz8niIQrBPNBJFCUAntu1boO3ciDkU0l4rl+6rT6gSIwaCB75M2eEvmdeJ4OrG3DFuGvuonqTDWhcFG+KObzAJJ/xLzxJ76XTfJovGZJbu+yaoq2wZ1N0yD9B79+MRkrqaxb0AD+Pwd/1CEzBD9e6hVyrHgh3XGwWq1s/qIoiFvNFSRrbERVq4tE8xksJ5n5Ur4O0cBw1FJoxhPFFu4a1XxiM3oacvw== 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 17.01.23 11:19, Vlastimil Babka wrote: > 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 > --- Thx for highlighting it and CCing me. Quick question: how fast do you think this should head towards mainline? The patch landed in next today, so that step in the process is already covered. But is the issue serious enough to say "send this to Linus after it was a day or two in next, so it can be quickly backported to stable"? > 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(-) > [...] In that case let me just briefly drop a link to the regression, as regzbot will notice that and file is as an activity. https://lore.kernel.org/lkml/20221216163227.24648-1-vbabka@suse.cz/ And simply consider your patch submission as a new report I track separately: #regzbot introduced ca3d76b0aa80 ^ https://bugzilla.suse.com/show_bug.cgi?id=1206359#c35 #regzbot title mm, mremap: another issue with mremap not fully fixed with the previous fix for the regression #regzbot fix: mm, mremap: fix mremap() expanding for vma's with vm_ops->close() #regzbot ignore-activity Not ideal, but that will make sure it's on regzbot radar (where way too many dots appear currently, as I'm a bit behind with things... :-/ ) Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.