From patchwork Wed Dec 18 19:50:20 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13914100 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A9528155C87; Wed, 18 Dec 2024 19:50:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734551421; cv=none; b=hsEFQhuOrCvIOWi9KKvaw6MQLBK4ao/QW7Yr2vcS85SZsOOxOFsIILKy5StTzqeDLbM8iMx7I+Ce1WKF/g0xgWgn1LL82SaujHlOcqeeOsY2mSl2eb2lMtZM7pROaPWJVLTuXURyq0hvSW+cKcd6SwDAzwsfy7dD0wvBKUMA6FI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734551421; c=relaxed/simple; bh=vqYZmsvcG6U/5Mh5MfuNRBOvNlC1AWXKUBNrgvbx+mY=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=P/DY8rF6ueDySQye6FhBfLV16rVi5m5IjSiNX/O+0aQ36AACgN/SH2gFSgpETVfnHefNo/FAgGqHynRxIZbSBHFjHwH+IrKRpte6m1LQ6QiD02sAnccBYeO5gPuT6PvzOdkm7v/65KpgjiPftuVCKE3kaQ65xHoPgapzHJN4zpI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Aw5e0iU/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Aw5e0iU/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33C76C4CECD; Wed, 18 Dec 2024 19:50:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734551421; bh=vqYZmsvcG6U/5Mh5MfuNRBOvNlC1AWXKUBNrgvbx+mY=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=Aw5e0iU/u/OSvZEsxrOI6XIbpvxlMGAXBK0LlYOq/v2XICGfYVRS4BGXO6zvE8W8k 6ppNaXmgIetHKbaLJfKoP4XeLlKrO95n0TaoL+NUCoykXS0IpCi9uWaPjcMVqL90tu fdPGf137FuFiJROlnZnr7mGabvz5HGE/w4Js2v5DV2BtdkaxWWTBmema7Nghk2umZn FhizRCOjkAQ/iHt4o5KjGfJXYUxlSmtBmcQhmPmmNYLi3l4vWWFuBwLkGIEJ78R2/z Y/1YKZvCKPpd1dmAonEmufUeRRsUB0NUBoN/9dBrKzgiPbqHKEk1ShRMS/d991JE8p l3nCsLEaAhu+g== Date: Wed, 18 Dec 2024 11:50:20 -0800 Subject: [PATCH 1/5] xfs: sb_spino_align is not verified From: "Darrick J. Wong" To: stable@vger.kernel.org, djwong@kernel.org Cc: dchinner@redhat.com, cem@kernel.org, linux-xfs@vger.kernel.org Message-ID: <173455093514.305755.18242328636177192354.stgit@frogsfrogsfrogs> In-Reply-To: <173455093488.305755.7686977865497104809.stgit@frogsfrogsfrogs> References: <173455093488.305755.7686977865497104809.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Dave Chinner commit 59e43f5479cce106d71c0b91a297c7ad1913176c upstream. It's just read in from the superblock and used without doing any validity checks at all on the value. Fixes: fb4f2b4e5a82 ("xfs: add sparse inode chunk alignment superblock field") Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino [djwong: actually tag for 6.12 because upstream maintainer ignored cc-stable tag] Link: https://lore.kernel.org/linux-xfs/20241024165544.GI21853@frogsfrogsfrogs/ Signed-off-by: "Darrick J. Wong" --- fs/xfs/libxfs/xfs_sb.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c index 02ebcbc4882f5b..9e0ae312bc8035 100644 --- a/fs/xfs/libxfs/xfs_sb.c +++ b/fs/xfs/libxfs/xfs_sb.c @@ -391,6 +391,20 @@ xfs_validate_sb_common( sbp->sb_inoalignmt, align); return -EINVAL; } + + if (!sbp->sb_spino_align || + sbp->sb_spino_align > sbp->sb_inoalignmt || + (sbp->sb_inoalignmt % sbp->sb_spino_align) != 0) { + xfs_warn(mp, + "Sparse inode alignment (%u) is invalid.", + sbp->sb_spino_align); + return -EINVAL; + } + } else if (sbp->sb_spino_align) { + xfs_warn(mp, + "Sparse inode alignment (%u) should be zero.", + sbp->sb_spino_align); + return -EINVAL; } } else if (sbp->sb_qflags & (XFS_PQUOTA_ENFD | XFS_GQUOTA_ENFD | XFS_PQUOTA_CHKD | XFS_GQUOTA_CHKD)) { From patchwork Wed Dec 18 19:50:36 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13914101 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15336157E82; Wed, 18 Dec 2024 19:50:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734551437; cv=none; b=krcFt0e++rbfgbHw7VnEX1Y+C373P++Mp/ux54aIXWRx4hnHE/JPxACXEPnPY0CE2+JckPbCcvp0/ogIZaZ925erfXZfP8O/ow0VClAiQtfQH5EKAN3VWmNOHl4XD1Lwx5CRJ/gahlTUUHiGCTS/P4RCPSj3tj4B5q9QJTWs3b8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734551437; c=relaxed/simple; bh=V3jQLWo1JewtY4J8x3XU6YBN7FktZWLUbZ3WyT0/emI=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nb2iA/2UzjBLR6kB/b6uT/logr9GPMkYyAMFzWLRdcqx8Cp2KEAwUSn9s8VYA5VEuGvUFeatkaDGp4Sqjq7IbwzpnjV8KK5DrNY4HJrrODbuYDgcw3OAr3TldrwFmTBr6lE/Bv1BnuYR98Ny2ImVjuQ818qwwYMCBqBG8O7+Da8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e7vph/rG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e7vph/rG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBD3EC4CECD; Wed, 18 Dec 2024 19:50:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734551436; bh=V3jQLWo1JewtY4J8x3XU6YBN7FktZWLUbZ3WyT0/emI=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=e7vph/rGpyHch4+OQ2xqTFf8BqxI3YdEvw8cF+XpsddunLgj7yyNOdGBx/+/jr5KP VdL5m4cIcX8kidASZNwXz4wOW0yBN1oBqaUGDiL3entZ09HcSvSMm9ik921wAxmGoR /acI+vZA7hqvl+NF+eQqSfa0TO3prcI7wzEy+PMOhuBTZWxVYZXXONTi7i3JKhkcqt oF8kVpzt7xAC9Tuft6Vm/Xy9Rp69J3TR+BlI0QUx1Y3zRVgrZAG/974vld5Opveq3W X5pYbXPFMgyt/ExhchLO6m4x4/3E5CHj61S62+ep6at5m++IXahKWqDmw+c6r04Yc1 rnh7igdJTT0Ug== Date: Wed, 18 Dec 2024 11:50:36 -0800 Subject: [PATCH 2/5] xfs: fix sparse inode limits on runt AG From: "Darrick J. Wong" To: stable@vger.kernel.org, djwong@kernel.org Cc: dchinner@redhat.com, cem@kernel.org, linux-xfs@vger.kernel.org Message-ID: <173455093530.305755.17997290982247743874.stgit@frogsfrogsfrogs> In-Reply-To: <173455093488.305755.7686977865497104809.stgit@frogsfrogsfrogs> References: <173455093488.305755.7686977865497104809.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Dave Chinner commit 13325333582d4820d39b9e8f63d6a54e745585d9 upstream. The runt AG at the end of a filesystem is almost always smaller than the mp->m_sb.sb_agblocks. Unfortunately, when setting the max_agbno limit for the inode chunk allocation, we do not take this into account. This means we can allocate a sparse inode chunk that overlaps beyond the end of an AG. When we go to allocate an inode from that sparse chunk, the irec fails validation because the agbno of the start of the irec is beyond valid limits for the runt AG. Prevent this from happening by taking into account the size of the runt AG when allocating inode chunks. Also convert the various checks for valid inode chunk agbnos to use xfs_ag_block_count() so that they will also catch such issues in the future. Fixes: 56d1115c9bc7 ("xfs: allocate sparse inode chunks on full chunk allocation failure") Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino [djwong: backport to stable because upstream maintainer ignored cc-stable] Link: https://lore.kernel.org/linux-xfs/20241112231539.GG9438@frogsfrogsfrogs/ Signed-off-by: "Darrick J. Wong" --- fs/xfs/libxfs/xfs_ialloc.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/fs/xfs/libxfs/xfs_ialloc.c b/fs/xfs/libxfs/xfs_ialloc.c index 271855227514cb..6258527315f28b 100644 --- a/fs/xfs/libxfs/xfs_ialloc.c +++ b/fs/xfs/libxfs/xfs_ialloc.c @@ -855,7 +855,8 @@ xfs_ialloc_ag_alloc( * the end of the AG. */ args.min_agbno = args.mp->m_sb.sb_inoalignmt; - args.max_agbno = round_down(args.mp->m_sb.sb_agblocks, + args.max_agbno = round_down(xfs_ag_block_count(args.mp, + pag->pag_agno), args.mp->m_sb.sb_inoalignmt) - igeo->ialloc_blks; @@ -2332,9 +2333,9 @@ xfs_difree( return -EINVAL; } agbno = XFS_AGINO_TO_AGBNO(mp, agino); - if (agbno >= mp->m_sb.sb_agblocks) { - xfs_warn(mp, "%s: agbno >= mp->m_sb.sb_agblocks (%d >= %d).", - __func__, agbno, mp->m_sb.sb_agblocks); + if (agbno >= xfs_ag_block_count(mp, pag->pag_agno)) { + xfs_warn(mp, "%s: agbno >= xfs_ag_block_count (%d >= %d).", + __func__, agbno, xfs_ag_block_count(mp, pag->pag_agno)); ASSERT(0); return -EINVAL; } @@ -2457,7 +2458,7 @@ xfs_imap( */ agino = XFS_INO_TO_AGINO(mp, ino); agbno = XFS_AGINO_TO_AGBNO(mp, agino); - if (agbno >= mp->m_sb.sb_agblocks || + if (agbno >= xfs_ag_block_count(mp, pag->pag_agno) || ino != XFS_AGINO_TO_INO(mp, pag->pag_agno, agino)) { error = -EINVAL; #ifdef DEBUG @@ -2467,11 +2468,12 @@ xfs_imap( */ if (flags & XFS_IGET_UNTRUSTED) return error; - if (agbno >= mp->m_sb.sb_agblocks) { + if (agbno >= xfs_ag_block_count(mp, pag->pag_agno)) { xfs_alert(mp, "%s: agbno (0x%llx) >= mp->m_sb.sb_agblocks (0x%lx)", __func__, (unsigned long long)agbno, - (unsigned long)mp->m_sb.sb_agblocks); + (unsigned long)xfs_ag_block_count(mp, + pag->pag_agno)); } if (ino != XFS_AGINO_TO_INO(mp, pag->pag_agno, agino)) { xfs_alert(mp, From patchwork Wed Dec 18 19:50:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13914102 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 28237155C87; Wed, 18 Dec 2024 19:50:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734551453; cv=none; b=gj4hPsRBAKnzG7c+mbShrJegwb/KgBHOJo8QTosWn5tcVw3L7i8GUF5locsfEINzGBmy123o3+vlFVRHlWt7i0qNrDBCmjFlfPR8LfUDxAwFJUmAdBpvNklTYcOE2mpEY/MYALOmyK50dzoRaFYbxo28AIIZF/SZOmCJ7iMXNP0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734551453; c=relaxed/simple; bh=IlzwpdlsgMLG86O/R02Vm5+HFlZIAyaj54wExYRLx6A=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dqsXGbcjNFhn88TNw1fX573ZvYPXm0t4f+ezeH6NnuWnOme3QecxoWpPjoETB+I8IffPu6Srwdvn6/qNx2bKTbbv2BJDGlONJC/v3n8VjPOd/sjcuHVvJXw4KxRkb/HBJ7sCEVpJV+bUDFYc8FTh1REBY7yQmjRQD5bbxOgPr5I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sCGS/AzY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sCGS/AzY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95A21C4CECD; Wed, 18 Dec 2024 19:50:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734551452; bh=IlzwpdlsgMLG86O/R02Vm5+HFlZIAyaj54wExYRLx6A=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=sCGS/AzYV3+yTmfD8yWUYW6KVhl4EAwucTTDk537SFToZ6zUHrAIyHHcNuknDKPvo WUoPT2BLcbXBU1/b7dZlW0IIskXianfNn/FSx1qdxLdH8ZUbvyDaJvQFZJSYK4Yrqz GKlQxnYXsXiHz6xCcf3HqFdAxctjMwPHaE5VSgUkMjg9ToEYsQmgSKkDkIAlrUGvtw x48JiQHNojET2cZIWirhuXm6D1BSc7m1sHV9jGtphj3/omW+CUoeGUYbPKJwRImv5V KiBC3g065HkoH2ffFtpqYeuDwVXTgh5SnCDo0vDROpf6pkx9RIsKdEnTM0sj+PCkD1 vyCgA0VtN14KA== Date: Wed, 18 Dec 2024 11:50:52 -0800 Subject: [PATCH 3/5] xfs: fix off-by-one error in fsmap's end_daddr usage From: "Darrick J. Wong" To: stable@vger.kernel.org, djwong@kernel.org Cc: wozizhi@huawei.com, hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <173455093546.305755.16195246941369372978.stgit@frogsfrogsfrogs> In-Reply-To: <173455093488.305755.7686977865497104809.stgit@frogsfrogsfrogs> References: <173455093488.305755.7686977865497104809.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong commit a440a28ddbdcb861150987b4d6e828631656b92f upstream. In commit ca6448aed4f10a, we created an "end_daddr" variable to fix fsmap reporting when the end of the range requested falls in the middle of an unknown (aka free on the rmapbt) region. Unfortunately, I didn't notice that the the code sets end_daddr to the last sector of the device but then uses that quantity to compute the length of the synthesized mapping. Zizhi Wo later observed that when end_daddr isn't set, we still don't report the last fsblock on a device because in that case (aka when info->last is true), the info->high mapping that we pass to xfs_getfsmap_group_helper has a startblock that points to the last fsblock. This is also wrong because the code uses startblock to compute the length of the synthesized mapping. Fix the second problem by setting end_daddr unconditionally, and fix the first problem by setting start_daddr to one past the end of the range to query. Cc: # v6.11 Fixes: ca6448aed4f10a ("xfs: Fix missing interval for missing_owner in xfs fsmap") Signed-off-by: "Darrick J. Wong" Reported-by: Zizhi Wo Reviewed-by: Christoph Hellwig --- fs/xfs/xfs_fsmap.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/fs/xfs/xfs_fsmap.c b/fs/xfs/xfs_fsmap.c index ae18ab86e608b5..8712b891defbc7 100644 --- a/fs/xfs/xfs_fsmap.c +++ b/fs/xfs/xfs_fsmap.c @@ -162,7 +162,8 @@ struct xfs_getfsmap_info { xfs_daddr_t next_daddr; /* next daddr we expect */ /* daddr of low fsmap key when we're using the rtbitmap */ xfs_daddr_t low_daddr; - xfs_daddr_t end_daddr; /* daddr of high fsmap key */ + /* daddr of high fsmap key, or the last daddr on the device */ + xfs_daddr_t end_daddr; u64 missing_owner; /* owner of holes */ u32 dev; /* device id */ /* @@ -306,7 +307,7 @@ xfs_getfsmap_helper( * Note that if the btree query found a mapping, there won't be a gap. */ if (info->last && info->end_daddr != XFS_BUF_DADDR_NULL) - rec_daddr = info->end_daddr; + rec_daddr = info->end_daddr + 1; /* Are we just counting mappings? */ if (info->head->fmh_count == 0) { @@ -898,7 +899,10 @@ xfs_getfsmap( struct xfs_trans *tp = NULL; struct xfs_fsmap dkeys[2]; /* per-dev keys */ struct xfs_getfsmap_dev handlers[XFS_GETFSMAP_DEVS]; - struct xfs_getfsmap_info info = { NULL }; + struct xfs_getfsmap_info info = { + .fsmap_recs = fsmap_recs, + .head = head, + }; bool use_rmap; int i; int error = 0; @@ -963,9 +967,6 @@ xfs_getfsmap( info.next_daddr = head->fmh_keys[0].fmr_physical + head->fmh_keys[0].fmr_length; - info.end_daddr = XFS_BUF_DADDR_NULL; - info.fsmap_recs = fsmap_recs; - info.head = head; /* For each device we support... */ for (i = 0; i < XFS_GETFSMAP_DEVS; i++) { @@ -978,17 +979,23 @@ xfs_getfsmap( break; /* - * If this device number matches the high key, we have - * to pass the high key to the handler to limit the - * query results. If the device number exceeds the - * low key, zero out the low key so that we get - * everything from the beginning. + * If this device number matches the high key, we have to pass + * the high key to the handler to limit the query results, and + * set the end_daddr so that we can synthesize records at the + * end of the query range or device. */ if (handlers[i].dev == head->fmh_keys[1].fmr_device) { dkeys[1] = head->fmh_keys[1]; info.end_daddr = min(handlers[i].nr_sectors - 1, dkeys[1].fmr_physical); + } else { + info.end_daddr = handlers[i].nr_sectors - 1; } + + /* + * If the device number exceeds the low key, zero out the low + * key so that we get everything from the beginning. + */ if (handlers[i].dev > head->fmh_keys[0].fmr_device) memset(&dkeys[0], 0, sizeof(struct xfs_fsmap)); From patchwork Wed Dec 18 19:51:07 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13914103 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DCAF9155C87; Wed, 18 Dec 2024 19:51:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734551469; cv=none; b=g1n5T3eLr+xi0xy9s5FsKPTz7lSHSRM4MCE237JbzNelkXOgj8PM4rC53O1zxFuUMOlDcxinvYsSEJ1iyed/uazVlm55++tBbWQ2LxLKRN4JaFiNtIEcdTi9PcWCe3Ux+h/P6hxLht6BvF0bA5VGnUeGPUrM9QDe2Jn4EUCxiVQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734551469; c=relaxed/simple; bh=MgiFm2ucMhp8vNXtOs5W1tD8ARsPIlL0yy1JIUMJQ1s=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ljN18lDXLjnzwDwWsVKcKqiuXauBG69uFNshe2pfv7DzTsi2xqC3cDdS90It/DW/NHVw2mkU4wreis46g9QY+u1iW1y4danP+cgHGvtLZ5tUi51CvLrph/a9hd9wgQegMGDdvAVx4RK2niC3qRLaV59VoA+5R451MrVJ9cp3kP8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PufoGnOj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PufoGnOj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5060DC4CECD; Wed, 18 Dec 2024 19:51:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734551468; bh=MgiFm2ucMhp8vNXtOs5W1tD8ARsPIlL0yy1JIUMJQ1s=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=PufoGnOj9LmjQObR8paRRvaZfnF9AfPdJ49C/YRStJKBm9R/j5VF4gytrKoU1FPf6 /aVskDs9lYVoAwiTrt8xSiXgdM2HUVi8l57h1gKtebLc5B9DMuXiyFl1Q5Jkm5JWfo 9TB+CpiGhdGWq5eOOo+dmLG4CB18Q/hZf/VqgxM/R7bdshwWHMH5XgQ70Qy3gLl+as dKm96soQkYBqpAd/9o2s7dHVQOV+fXi7WmOOj6lM7eI5ZLkJ2ZgKbOJbatkrSNVa2Z XMG3HgLUmnnUbmWgTVZaTxtilDr8hqBpXNdH3Aghl8WqLGCa1mlDPrxqR3mY/VOHpk i1hZxs325wO4w== Date: Wed, 18 Dec 2024 11:51:07 -0800 Subject: [PATCH 4/5] xfs: fix sb_spino_align checks for large fsblock sizes From: "Darrick J. Wong" To: stable@vger.kernel.org, djwong@kernel.org Cc: hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <173455093563.305755.14124909419754195900.stgit@frogsfrogsfrogs> In-Reply-To: <173455093488.305755.7686977865497104809.stgit@frogsfrogsfrogs> References: <173455093488.305755.7686977865497104809.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong commit 7f8a44f37229fc76bfcafa341a4b8862368ef44a upstream. For a sparse inodes filesystem, mkfs.xfs computes the values of sb_spino_align and sb_inoalignmt with the following code: int cluster_size = XFS_INODE_BIG_CLUSTER_SIZE; if (cfg->sb_feat.crcs_enabled) cluster_size *= cfg->inodesize / XFS_DINODE_MIN_SIZE; sbp->sb_spino_align = cluster_size >> cfg->blocklog; sbp->sb_inoalignmt = XFS_INODES_PER_CHUNK * cfg->inodesize >> cfg->blocklog; On a V5 filesystem with 64k fsblocks and 512 byte inodes, this results in cluster_size = 8192 * (512 / 256) = 16384. As a result, sb_spino_align and sb_inoalignmt are both set to zero. Unfortunately, this trips the new sb_spino_align check that was just added to xfs_validate_sb_common, and the mkfs fails: # mkfs.xfs -f -b size=64k, /dev/sda meta-data=/dev/sda isize=512 agcount=4, agsize=81136 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=0 metadir=0 data = bsize=65536 blocks=324544, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=65536 ascii-ci=0, ftype=1, parent=0 log =internal log bsize=65536 blocks=5006, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=65536 blocks=0, rtextents=0 = rgcount=0 rgsize=0 extents Discarding blocks...Sparse inode alignment (0) is invalid. Metadata corruption detected at 0x560ac5a80bbe, xfs_sb block 0x0/0x200 libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x1 mkfs.xfs: Releasing dirty buffer to free list! found dirty buffer (bulk) on free list! Sparse inode alignment (0) is invalid. Metadata corruption detected at 0x560ac5a80bbe, xfs_sb block 0x0/0x200 libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x1 mkfs.xfs: writing AG headers failed, err=22 Prior to commit 59e43f5479cce1 this all worked fine, even if "sparse" inodes are somewhat meaningless when everything fits in a single fsblock. Adjust the checks to handle existing filesystems. Cc: # v6.13-rc1 Fixes: 59e43f5479cce1 ("xfs: sb_spino_align is not verified") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig --- fs/xfs/libxfs/xfs_sb.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c index 9e0ae312bc8035..e27b63281d012a 100644 --- a/fs/xfs/libxfs/xfs_sb.c +++ b/fs/xfs/libxfs/xfs_sb.c @@ -392,12 +392,13 @@ xfs_validate_sb_common( return -EINVAL; } - if (!sbp->sb_spino_align || - sbp->sb_spino_align > sbp->sb_inoalignmt || - (sbp->sb_inoalignmt % sbp->sb_spino_align) != 0) { + if (sbp->sb_spino_align && + (sbp->sb_spino_align > sbp->sb_inoalignmt || + (sbp->sb_inoalignmt % sbp->sb_spino_align) != 0)) { xfs_warn(mp, - "Sparse inode alignment (%u) is invalid.", - sbp->sb_spino_align); +"Sparse inode alignment (%u) is invalid, must be integer factor of (%u).", + sbp->sb_spino_align, + sbp->sb_inoalignmt); return -EINVAL; } } else if (sbp->sb_spino_align) { From patchwork Wed Dec 18 19:51:23 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13914104 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5FB66155C87; Wed, 18 Dec 2024 19:51:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734551484; cv=none; b=GJEh9jSeWYlwmKXQP4jMA/33+hag/zTLj6HrY0eaJ0z4g4lUIKPvKJaXoHe+ubSKPNaJI6oRA53BBfSCqteIXqxn2bgw1u5qUos7cmGEyje4i+YFE4LAWCzMVimGffmq96HsuNkslQ7NnCgAWo7Z/dMnpp+jX3tusAcifbnh17s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734551484; c=relaxed/simple; bh=qhYporBeqPCMQnPqEVYxLDJqj1HPniraK8ToDLq9N5s=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Nn0pzVyJEmhZG994yH6tNdUmJJ7e5jnEjjOnb7MOFCbdpNSIlfscay/FSv413OgLkewFOkykHaSgjttHpb4avS2WbHuy2BOMj0bk7qUFtYHUWsXppElIwj0MMsIi81X/MpYyCO8Jbkz76BrrKjlhsTwBNbidiZfQ3BgiC28qEsQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tFPjXnzF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tFPjXnzF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EEA98C4CECD; Wed, 18 Dec 2024 19:51:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734551484; bh=qhYporBeqPCMQnPqEVYxLDJqj1HPniraK8ToDLq9N5s=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=tFPjXnzFBuO/zrilmsvFquLUNAHPWiAcZwVJgUC52txU78rU7JS/bRU3g5uTOlZS7 pIz003k65qSqUVXlV0Z9Bn9V+eZmx0elUE5H+P4qxIY7PRJTQSUxM6f0PIUWIGz/SP RpwZFWKluRqdbllQ8WRiRcGdOVD+CA0bkXOOrfAFtzKicrC+wpL/64h5YUGHLjMhcL ZH02zQwsanwtAKNNH2kzpO/1z7jgESd7ooIZj89SnMLni+E7Fq8yeM61LFTrZPmd3G xsqI35aO3CXwrCR/6sNs16l+JtfD903kht7/Kf8aRjddDgtjlvui+m3LOhZpf1z+5M g6INOuQgh+wyw== Date: Wed, 18 Dec 2024 11:51:23 -0800 Subject: [PATCH 5/5] xfs: fix zero byte checking in the superblock scrubber From: "Darrick J. Wong" To: stable@vger.kernel.org, djwong@kernel.org Cc: hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <173455093579.305755.3960848373109465926.stgit@frogsfrogsfrogs> In-Reply-To: <173455093488.305755.7686977865497104809.stgit@frogsfrogsfrogs> References: <173455093488.305755.7686977865497104809.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong commit c004a793e0ec34047c3bd423bcd8966f5fac88dc upstream. The logic to check that the region past the end of the superblock is all zeroes is wrong -- we don't want to check only the bytes past the end of the maximally sized ondisk superblock structure as currently defined in xfs_format.h; we want to check the bytes beyond the end of the ondisk as defined by the feature bits. Port the superblock size logic from xfs_repair and then put it to use in xfs_scrub. Cc: # v4.15 Fixes: 21fb4cb1981ef7 ("xfs: scrub the secondary superblocks") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig --- fs/xfs/scrub/agheader.c | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/fs/xfs/scrub/agheader.c b/fs/xfs/scrub/agheader.c index da30f926cbe66d..0f2f1852d58fe7 100644 --- a/fs/xfs/scrub/agheader.c +++ b/fs/xfs/scrub/agheader.c @@ -59,6 +59,30 @@ xchk_superblock_xref( /* scrub teardown will take care of sc->sa for us */ } +/* + * Calculate the ondisk superblock size in bytes given the feature set of the + * mounted filesystem (aka the primary sb). This is subtlely different from + * the logic in xfs_repair, which computes the size of a secondary sb given the + * featureset listed in the secondary sb. + */ +STATIC size_t +xchk_superblock_ondisk_size( + struct xfs_mount *mp) +{ + if (xfs_has_metauuid(mp)) + return offsetofend(struct xfs_dsb, sb_meta_uuid); + if (xfs_has_crc(mp)) + return offsetofend(struct xfs_dsb, sb_lsn); + if (xfs_sb_version_hasmorebits(&mp->m_sb)) + return offsetofend(struct xfs_dsb, sb_bad_features2); + if (xfs_has_logv2(mp)) + return offsetofend(struct xfs_dsb, sb_logsunit); + if (xfs_has_sector(mp)) + return offsetofend(struct xfs_dsb, sb_logsectsize); + /* only support dirv2 or more recent */ + return offsetofend(struct xfs_dsb, sb_dirblklog); +} + /* * Scrub the filesystem superblock. * @@ -75,6 +99,7 @@ xchk_superblock( struct xfs_buf *bp; struct xfs_dsb *sb; struct xfs_perag *pag; + size_t sblen; xfs_agnumber_t agno; uint32_t v2_ok; __be32 features_mask; @@ -350,8 +375,8 @@ xchk_superblock( } /* Everything else must be zero. */ - if (memchr_inv(sb + 1, 0, - BBTOB(bp->b_length) - sizeof(struct xfs_dsb))) + sblen = xchk_superblock_ondisk_size(mp); + if (memchr_inv((char *)sb + sblen, 0, BBTOB(bp->b_length) - sblen)) xchk_block_set_corrupt(sc, bp); xchk_superblock_xref(sc, bp);