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 A5F54C004D4 for ; Thu, 19 Jan 2023 14:49:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05C0D6B0072; Thu, 19 Jan 2023 09:49:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 00CA66B0073; Thu, 19 Jan 2023 09:49:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E16716B0074; Thu, 19 Jan 2023 09:49:18 -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 D258C6B0072 for ; Thu, 19 Jan 2023 09:49:18 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A56F380173 for ; Thu, 19 Jan 2023 14:49:18 +0000 (UTC) X-FDA: 80371831596.08.D98774E Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf01.hostedemail.com (Postfix) with ESMTP id A454340017 for ; Thu, 19 Jan 2023 14:49:16 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=SXEWsqfC; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=0uH9M1oL; spf=pass (imf01.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 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=1674139756; 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=DPS4obwwsmfPtCuVpCuOX+Y34p5KNkQnrFysGNasucA=; b=HNKQItIuBHV2mSHkmJXNSiNNxruU869FeePhcg6T1K2N3j5AknkkFo0UgfzlXwQTEwQIVw G6tPFKCFsmky7O+0z3gywNXEp8x3D2VbkC/eJuhueosSGZsOYOa0FZ+hnrow+KkR8IUru7 7vZ3fNydqZCSHmV1AXEI0mpd+Q65mmc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=SXEWsqfC; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=0uH9M1oL; spf=pass (imf01.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674139756; a=rsa-sha256; cv=none; b=HHUTNSfFlqZOoLivbZ0W91tKAWShquBCQZ4waybhZo5cgtqEoiFA4z7b3akkjmDa3mSTuw Jmny4y7PcFHThtBYu1OI4Pqsp8q4qLh+t8mZBeFQugRgjG3Ehh+zornKQRDPWGHSXjuibA Ap6uU9HraubyTs5vMiodQmOmeQiTrDw= 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-out2.suse.de (Postfix) with ESMTPS id 13B49208B8; Thu, 19 Jan 2023 14:49:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1674139754; 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=DPS4obwwsmfPtCuVpCuOX+Y34p5KNkQnrFysGNasucA=; b=SXEWsqfCR02LELaF+lEocgRPIQEH0/KaC1PeLFzh7CwYvNJYGyNgbf7C47jaQjlRBmjuLv lKxNBfOt22gvtIjJqCcTDyk2yxWnOXXwbl22RcLQB+YDfzjm3wxgytxod2acEX+DZgct7i XZjWUySRyc/P9OmK2OuXKljEgWSTlH0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1674139754; 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=DPS4obwwsmfPtCuVpCuOX+Y34p5KNkQnrFysGNasucA=; b=0uH9M1oLQ4hpPtsy4jOkl/VNbFm+mHAJY9ZowysrEtElD8Qzzn2wo7oy2HW+PZ/FNC+rUl amKX1wOF2qY4A9Ag== 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 E841E139ED; Thu, 19 Jan 2023 14:49:13 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id NTwpOGlYyWPlMQAAMHmgww (envelope-from ); Thu, 19 Jan 2023 14:49:13 +0000 Message-ID: Date: Thu, 19 Jan 2023 15:49:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH for 6.1 regression] mm, mremap: fix mremap() expanding for vma's with vm_ops->close() Content-Language: en-US To: Linux regressions mailing list , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Fabian Vogt , =?UTF-8?Q?Jakub_Mat=c4=9bna?= , stable@vger.kernel.org, Thorsten Leemhuis References: <20230117101939.9753-1-vbabka@suse.cz> <2f03bd25-bfa1-a8fe-558e-ae3ce22b97fa@leemhuis.info> From: Vlastimil Babka In-Reply-To: <2f03bd25-bfa1-a8fe-558e-ae3ce22b97fa@leemhuis.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A454340017 X-Stat-Signature: ueab61kzjgrjmis1az54dg38ezcqop6a X-Rspam-User: X-HE-Tag: 1674139756-107072 X-HE-Meta: U2FsdGVkX18TVDerugq9DpCx7pykMUdgX545tOSrZWs+qUYql6V5mfl2XqvT8ptIT2xhSFefL8HI48TcFqqIQ3bn5SpIDMGkW7Z+WrQqXqmt9ncGXoYJmwGZEsZG7M72OZ3ke89N5Li902oz2ImZR42RTx82tdzP5CFRFYc1SsKufSRPGAULFbjFbqHWkNM1mUVOu9v+5y9GrkMLNuy1DVIwtGXsMRo3RlRpeF2UKPmqXyqffunojxh2ldRM6buDne2PaKhhkWrjheDdJXVwYfi4VQmRWqeYaqIlVImfSa9LZaCDdnsvumevdhrhn+SMcEIHzz6A4A7LYUzIhfRrz1u4+VElvFUMKBsJBX4yRzkPanjbKx2nVH2fBUArfnhWZAqil/RRqhyLcQSrIeA5Z2NqTT6J3wsDCIK9fJoJKHw3JmqZaYLL3k1lmEaIevB97EHJTnSX279cfOSyWqQ1nRN3hWpD5uF3qfyJjWqBhuvu+vavlPe42K2rhjrRCbJZniMD14/0p4iw/OafqtnW0YVWPXPLE9xBj1fXB6s4Kc72BlgbrKOHzupH+/GWzXBl4qO9boRCm0IfxaGuacg3OrNLpqCm3L4GCWnKE6cUwCwhBwCh9p6wpweU+SyKmRb9cz2Pb68r4AmPSf+7gpDQe6X/QIQsTUshWX4C5Zc4YwambSmVjXMFiv6ZFb+5LD1gCSw2VXz7mozKdcM2hzPhhDECKf57RfviIEh4azh3aqTcVE0HOr6AXy6yzBqWxXHya256lfHl4EMeAyY07Ad4EwhL/KaHsJ1nAbyq24VANVmQqshZwO2vr62SGZpkgNxCtNgmktiFuQzhNxIIjVcNf99jdoQtJ9pA3Thw4/jVqBCbjWdBUDcZTBuuNiKd0AnThaftblQtdzeNOQdALIfQgRqAT2Y1kt8XPLQdIO00T50R7QYskcZ2UWdFuwgBn//SFu8qoHRflfeufVnXNup Jmw== 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 1/19/23 14:37, Linux kernel regression tracking (Thorsten Leemhuis) wrote: > 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"? I think it's not as serious as the previous one, the conditions should be more rare. But you made me realize I should probably reply to the "stalls in qemu" one in that sense. Thanks! >> 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.