Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp651045iog; Thu, 30 Jun 2022 07:41:51 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t4hnOCOlFS39tTJFY4hPiAI3+bD5/Pp1RW/XuBpLCSnSxxaN3Qe64BrbWzjVBQNACKKqSx X-Received: by 2002:a05:6402:128c:b0:435:6a3b:3a0a with SMTP id w12-20020a056402128c00b004356a3b3a0amr12113239edv.237.1656600111467; Thu, 30 Jun 2022 07:41:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656600111; cv=none; d=google.com; s=arc-20160816; b=lgznHbYPI7gVUMsSE/QFtvVrDMfeePO04leEh6BSVbJlVgoUskE2bvvjBaCF8p0gsV iHa5r2afV+RRYBqTXh59KVdU7b4udghx5uqjHQLl+Mim/JEaveN+v02jB1sf9qdt36zV 0dHWTu4AqxrVzdve+N5fiz0sZ3r4Nys7NJoqKaWEHCW/SZN0XeqSfOrTIiZL9IUIa5lF mozocb2BsmiuA9pNfHGXplZJMr1tXOgHcnn5r8XYAi8GI7Tp40jVYnCt3AXPs6M53s4f iq1tW628jkQI+5gzE66V+/3giIECcS8sJTz87N7IpUOp7yZJpHVtwihbO8g6/nB97h1U J7eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=MceqooyGn9VujbVYVchAGwBDzxO2nUxe5skzGDIFa94=; b=usZZTJP/V4ZKctYVaORjfGmsAgYfOb4TehSsilQ3hrFU7YOVA2rKJqcM82rmBvFm3m nOfkglUlEW/9L6V3rMutgSENH27uRIvo5bzgVNqBFkLu2zTU9xfDGescY7ODPfGmv4D+ 1epdGVvW+tipwn6VebWuV9DqpCdm2Xy22XQKtohAlVpVbbNIzdCxIaLAOaXF5UPlZAjb U/cjdOpeDCgKCCWtm5S1atb1Lw+ygz3kZj9LNOGniZYjeDqUaIJhS/yC7xLOWEJldW9t xOpUxR2X73on4BKqoV7MVpZez9kpRj6zDKz/uiJQOcHg03NL3oxXcwNFRPXMSHbAdSDz FkKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="B40z93/w"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sg10-20020a170907a40a00b0072a4b4fb1e0si5319287ejc.911.2022.06.30.07.41.26; Thu, 30 Jun 2022 07:41:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="B40z93/w"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236630AbiF3OI6 (ORCPT + 99 others); Thu, 30 Jun 2022 10:08:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236998AbiF3OID (ORCPT ); Thu, 30 Jun 2022 10:08:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E36B658FCE; Thu, 30 Jun 2022 06:54:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A5D7161F60; Thu, 30 Jun 2022 13:54:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5406C34115; Thu, 30 Jun 2022 13:54:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656597298; bh=WSC4Ty7X9kVE4lplSVd+NK0Bnrgsp6SoIYov4oT+WTE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B40z93/wtVxbFkoCrN4KR9gCDfP65ptw9c6f9IpZUsaav0pxz7KUBQ2YDqitw9EdY Er17YgSdxy/ghRSy+yxZL0BUqodU67AMxqkrDC7rXIop2KldDrF+L17LTPCiX1t7rI PHhgpCmIspZagX06pswEu5HU3NBllH2znQkiOX9M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , "Darrick J. Wong" , Dave Chinner , Chandan Babu R , Leah Rumancik Subject: [PATCH 5.15 08/28] xfs: remove all COW fork extents when remounting readonly Date: Thu, 30 Jun 2022 15:47:04 +0200 Message-Id: <20220630133233.172093513@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220630133232.926711493@linuxfoundation.org> References: <20220630133232.926711493@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Darrick J. Wong" [ Upstream commit 089558bc7ba785c03815a49c89e28ad9b8de51f9 ] As part of multiple customer escalations due to file data corruption after copy on write operations, I wrote some fstests that use fsstress to hammer on COW to shake things loose. Regrettably, I caught some filesystem shutdowns due to incorrect rmap operations with the following loop: mount # (0) fsstress & # (1) while true; do fsstress mount -o remount,ro # (2) fsstress mount -o remount,rw # (3) done When (2) happens, notice that (1) is still running. xfs_remount_ro will call xfs_blockgc_stop to walk the inode cache to free all the COW extents, but the blockgc mechanism races with (1)'s reader threads to take IOLOCKs and loses, which means that it doesn't clean them all out. Call such a file (A). When (3) happens, xfs_remount_rw calls xfs_reflink_recover_cow, which walks the ondisk refcount btree and frees any COW extent that it finds. This function does not check the inode cache, which means that incore COW forks of inode (A) is now inconsistent with the ondisk metadata. If one of those former COW extents are allocated and mapped into another file (B) and someone triggers a COW to the stale reservation in (A), A's dirty data will be written into (B) and once that's done, those blocks will be transferred to (A)'s data fork without bumping the refcount. The results are catastrophic -- file (B) and the refcount btree are now corrupt. Solve this race by forcing the xfs_blockgc_free_space to run synchronously, which causes xfs_icwalk to return to inodes that were skipped because the blockgc code couldn't take the IOLOCK. This is safe to do here because the VFS has already prohibited new writer threads. Fixes: 10ddf64e420f ("xfs: remove leftover CoW reservations when remounting ro") Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Reviewed-by: Chandan Babu R Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman --- fs/xfs/xfs_super.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1768,7 +1768,10 @@ static int xfs_remount_ro( struct xfs_mount *mp) { - int error; + struct xfs_icwalk icw = { + .icw_flags = XFS_ICWALK_FLAG_SYNC, + }; + int error; /* * Cancel background eofb scanning so it cannot race with the final @@ -1776,8 +1779,13 @@ xfs_remount_ro( */ xfs_blockgc_stop(mp); - /* Get rid of any leftover CoW reservations... */ - error = xfs_blockgc_free_space(mp, NULL); + /* + * Clear out all remaining COW staging extents and speculative post-EOF + * preallocations so that we don't leave inodes requiring inactivation + * cleanups during reclaim on a read-only mount. We must process every + * cached inode, so this requires a synchronous cache scan. + */ + error = xfs_blockgc_free_space(mp, &icw); if (error) { xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE); return error;