Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp1012290pxx; Tue, 27 Oct 2020 06:18:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmmiiizqOt/K6oe2rNURZd0MLMJiBZobv+Z2mMMYtMN7R3ny3gfq2aX+1ai7e9CJjloSv5 X-Received: by 2002:a17:906:1f08:: with SMTP id w8mr2349691ejj.181.1603804712665; Tue, 27 Oct 2020 06:18:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603804712; cv=none; d=google.com; s=arc-20160816; b=XcXjRgejoqXi110MxTsZ1sclpf+D0KyU8kYv7CqO4covOv0OQ7kk5oHF/Jex0fbi3/ XGjsJiq4HtZSeA1qawCPIjAbqwLbyFENRO8W6S1xY6qIojSfN1bPUB2bzzRKFJ7VHmTi 6qnRnaoy2fCKcGKCetFQBXSqKfuWvnSi2Jr+hxsCsp3bY+Bi2f36AQN+eEOyo7YQJQ+1 6xfomxcQMxDR5ZNtNq2tVMAR3DqfQvBSKr0rq1Yiy5ksB7dDYS8ixfvzu99e30PkH5ny MWncF/cdQMobCyngzELaIiA7vnchLQQHlQ2Vnqy9jQCepvFmldgEGWeUsoonL2MhQHi5 uxpw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=jmQxsEAb7NtCMej0z3pdUuBIAodD8xc2yajQOvCEoBA=; b=w5jrt26NoM2GL9kM/X9uAsbB5gq3bSS7sOCfV1gorKZyFfsP1TY5pi1nFJlDktd7oy H4Q+FbM3uvpL3uNytBwjYoDlTv0ZI0RM3nyQn548zh5EeClbeLZWdOJWp8pRuRD+qDEZ p7A0Q8x48dlH++/7E1MJb9J32l4fqTmyqqIs7+Z59JlEJu4/YpJjYXVJS+BvZrCaL9/9 US4pwUmfhaArOeOVqmTFH6AIPYJCdbyyZ9yGCgNyUSzhWZ9V7BoUZUL7Vb1HaXRHua0K sPMN56y+t3KBV/PoOgkr9WG1kaxTyC5AsRZjS0NmTUvR9uo16qiEsakbdcKQLOeL3C99 glXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vP9bmmza; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m20si857183edp.87.2020.10.27.06.18.07; Tue, 27 Oct 2020 06:18:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vP9bmmza; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2441374AbgJ0AXB (ORCPT + 99 others); Mon, 26 Oct 2020 20:23:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:33740 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2410920AbgJZXzg (ORCPT ); Mon, 26 Oct 2020 19:55:36 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E7CE720B1F; Mon, 26 Oct 2020 23:55:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603756535; bh=ACYIHEfNgVHqI+C07BuMcJ2NoOu80l8jDu2L0GJUl8U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vP9bmmzaIXQVFae2r+ZqnN3htfRm0m15CkTgB+spwd0GxPq6eKwGjAgDR8Ym6+RAL ORIvyPH2iMe6go+MsUdV//7fTpbdYUFJmU/hJ+wBgzeQxcmT8InSUSIztDMlWGiUY0 Zj3RWwxGR2d52vVKksG/mVcBEXeGY6Bvv+4F78Cc= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Darrick J. Wong" , Chandan Babu R , Sasha Levin , linux-xfs@vger.kernel.org Subject: [PATCH AUTOSEL 5.4 15/80] xfs: fix realtime bitmap/summary file truncation when growing rt volume Date: Mon, 26 Oct 2020 19:54:11 -0400 Message-Id: <20201026235516.1025100-15-sashal@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20201026235516.1025100-1-sashal@kernel.org> References: <20201026235516.1025100-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Darrick J. Wong" [ Upstream commit f4c32e87de7d66074d5612567c5eac7325024428 ] The realtime bitmap and summary files are regular files that are hidden away from the directory tree. Since they're regular files, inode inactivation will try to purge what it thinks are speculative preallocations beyond the incore size of the file. Unfortunately, xfs_growfs_rt forgets to update the incore size when it resizes the inodes, with the result that inactivating the rt inodes at unmount time will cause their contents to be truncated. Fix this by updating the incore size when we change the ondisk size as part of updating the superblock. Note that we don't do this when we're allocating blocks to the rt inodes because we actually want those blocks to get purged if the growfs fails. This fixes corruption complaints from the online rtsummary checker when running xfs/233. Since that test requires rmap, one can also trigger this by growing an rt volume, cycling the mount, and creating rt files. Signed-off-by: Darrick J. Wong Reviewed-by: Chandan Babu R Signed-off-by: Sasha Levin --- fs/xfs/xfs_rtalloc.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c index 4a48a8c75b4f7..23ada3b3ea96c 100644 --- a/fs/xfs/xfs_rtalloc.c +++ b/fs/xfs/xfs_rtalloc.c @@ -1010,10 +1010,13 @@ xfs_growfs_rt( xfs_ilock(mp->m_rbmip, XFS_ILOCK_EXCL); xfs_trans_ijoin(tp, mp->m_rbmip, XFS_ILOCK_EXCL); /* - * Update the bitmap inode's size. + * Update the bitmap inode's size ondisk and incore. We need + * to update the incore size so that inode inactivation won't + * punch what it thinks are "posteof" blocks. */ mp->m_rbmip->i_d.di_size = nsbp->sb_rbmblocks * nsbp->sb_blocksize; + i_size_write(VFS_I(mp->m_rbmip), mp->m_rbmip->i_d.di_size); xfs_trans_log_inode(tp, mp->m_rbmip, XFS_ILOG_CORE); /* * Get the summary inode into the transaction. @@ -1021,9 +1024,12 @@ xfs_growfs_rt( xfs_ilock(mp->m_rsumip, XFS_ILOCK_EXCL); xfs_trans_ijoin(tp, mp->m_rsumip, XFS_ILOCK_EXCL); /* - * Update the summary inode's size. + * Update the summary inode's size. We need to update the + * incore size so that inode inactivation won't punch what it + * thinks are "posteof" blocks. */ mp->m_rsumip->i_d.di_size = nmp->m_rsumsize; + i_size_write(VFS_I(mp->m_rsumip), mp->m_rsumip->i_d.di_size); xfs_trans_log_inode(tp, mp->m_rsumip, XFS_ILOG_CORE); /* * Copy summary data from old to new sizes. -- 2.25.1