[PATCH 10/12] xfs: opportunistically skip btree block checks

[PATCH 10/12] xfs: opportunistically skip btree block checks

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM notices that both callers of xchk_btree_get_block will return
early if *pblock is NULL after a successful return.  However,
xchk_btree_get_block itself can return 0 after flagging a corruption.
There's no point in continuing after we've found a corruption, so null
the pointer out.

Cc: <stable@vger.kernel.org> # v4.15
Fixes: cc3e0948d2686f ("xfs: scrub the shape of a metadata btree")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
---
 fs/xfs/scrub/btree.c |    1 +
 1 file changed, 1 insertion(+)


diff --git a/fs/xfs/scrub/btree.c b/fs/xfs/scrub/btree.c
index 786b1e7c4dc37f..43b81432640777 100644
--- a/fs/xfs/scrub/btree.c
+++ b/fs/xfs/scrub/btree.c
@@ -602,6 +602,7 @@ xchk_btree_get_block(
 	xfs_btree_get_block(bs->cur, level, pbp);
 	if (__xfs_btree_check_block(bs->cur, *pblock, level, *pbp)) {
 		xchk_btree_set_corrupt(bs->sc, bs->cur, level);
+		*pblock = NULL;
 		return 0;
 	}
 	if (*pbp)

[PATCHSET v2 1/2] xfs: LLM-inspired bug fixes, part 22

[Darrick J. Wong]

Hi all,

Here's a twenty-second batch of xfs fixes resulting from a LLaMma.  Mwa
mwa mwa...

v2: fix issues pointed out by reviewers.

If you're going to start using this code, I strongly recommend pulling
from my git trees, which are linked below.

With a bit of luck, this should all go splendidly.
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=llm-fixes-22
---
Commits in this patchset:
 * xfs: don't overrun incore inode when cleaning attr forks
 * xfs: fix data fork block count check in xrep_inode_blockcounts
 * xfs: avoid oversized space allocations when regenerating metadata
 * xfs: reduce new btree slack factor if free space is negative
 * xfs: don't queue rmap update twice when reaping a fork
 * xfs: only written file data blocks can be shared
 * xfs: check for fragments when full-extent sharing matches
 * xfs: don't clear COWEXTSIZE on directories on reflink filesystems
 * xfs: clear set[ug]id mode bits when zapping attr fork
 * xfs: opportunistically skip btree block checks
 * xfs: always report scrub errors in tracepoints
 * xfs: don't scan across metadata/regular directory trees for dirents
---
 fs/xfs/scrub/btree.c        |   16 +++++++++++++++-
 fs/xfs/scrub/common.c       |    7 +++++--
 fs/xfs/scrub/dabtree.c      |    6 +++++-
 fs/xfs/scrub/dir_repair.c   |    4 +++-
 fs/xfs/scrub/inode_repair.c |   13 +++++++++++--
 fs/xfs/scrub/newbt.c        |    6 +++---
 fs/xfs/scrub/reap.c         |    4 ++--
 fs/xfs/scrub/refcount.c     |   17 ++++++++++++++++-
 fs/xfs/scrub/rtrefcount.c   |   17 ++++++++++++++++-
 9 files changed, 76 insertions(+), 14 deletions(-)

Unreviewed in this series:

[PATCHSET v2 1/2] xfs: LLM-inspired bug fixes, part 22
  [PATCH 04/12] xfs: reduce new btree slack factor if free space is
  [PATCH 06/12] xfs: only written file data blocks can be shared
  [PATCH 10/12] xfs: opportunistically skip btree block checks

[PATCH 01/12] xfs: don't overrun incore inode when cleaning attr forks

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM noticed that xrep_dinode_check_afork doesn't check for a
di_forkoff value that is so large that the attr fork would begin after
the end of the inode space.  This causes afork_{ptr,size} to be
nonsense.  What we really ought to do here is zap the attr fork.

Cc: <stable@vger.kernel.org> # v6.8
Fixes: e744cef2060559 ("xfs: zap broken inode forks")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/scrub/inode_repair.c |    2 ++
 1 file changed, 2 insertions(+)


diff --git a/fs/xfs/scrub/inode_repair.c b/fs/xfs/scrub/inode_repair.c
index 5b5116adcbf5e4..de3c915984290b 100644
--- a/fs/xfs/scrub/inode_repair.c
+++ b/fs/xfs/scrub/inode_repair.c
@@ -1243,6 +1243,8 @@ xrep_dinode_check_afork(
 	if (XFS_DFORK_BOFF(dip) == 0)
 		return dip->di_aformat != XFS_DINODE_FMT_EXTENTS ||
 		       xfs_dfork_attr_extents(dip) != 0;
+	if (XFS_DFORK_BOFF(dip) >= XFS_LITINO(sc->mp))
+		return true;
 
 	afork_size = XFS_DFORK_SIZE(dip, sc->mp, XFS_ATTR_FORK);
 	afork_ptr = XFS_DFORK_PTR(dip, XFS_ATTR_FORK);

[PATCH 02/12] xfs: fix data fork block count check in xrep_inode_blockcounts

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM notices that for non-reflink realtime files, the @count output of
xchk_inode_count_blocks includes both the file blocks on the realtime
volume and the bmap btree blocks on the data volume.  Therefore, we must
compare this value to rblocks + dblocks to avoid unnecessary failure.

Cc: <stable@vger.kernel.org> # v6.8
Fixes: 2d295fe65776d1 ("xfs: repair inode records")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/scrub/inode_repair.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/fs/xfs/scrub/inode_repair.c b/fs/xfs/scrub/inode_repair.c
index de3c915984290b..89cbf599795b2f 100644
--- a/fs/xfs/scrub/inode_repair.c
+++ b/fs/xfs/scrub/inode_repair.c
@@ -1719,7 +1719,7 @@ xrep_inode_blockcounts(
 		 */
 		;
 	} else if (XFS_IS_REALTIME_INODE(sc->ip)) {
-		if (count >= sc->mp->m_sb.sb_rblocks)
+		if (count >= sc->mp->m_sb.sb_rblocks + sc->mp->m_sb.sb_dblocks)
 			return -EFSCORRUPTED;
 	} else {
 		if (count >= sc->mp->m_sb.sb_dblocks)

[PATCH 04/12] xfs: reduce new btree slack factor if free space is negative

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM points out that if the incore fdblocks counter is negative, the
assignment to uint64_t will mask this possibly low space situation and
we don't pack the btree blocks as tightly as we probably ought to.  If
it's the case that there's some free space and fdblocks is too low due
to an error in the superblock field, then we can end up failing btree
rebuilds due to ENOSPC unnecessarily.  This is a corner case, but let's
fix it anyway.

Cc: <stable@vger.kernel.org> # v6.8
Fixes: be408417630427 ("xfs: implement block reservation accounting for btrees we're staging")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
---
 fs/xfs/scrub/newbt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/fs/xfs/scrub/newbt.c b/fs/xfs/scrub/newbt.c
index 1f28ca1647f8d3..9baf08bc54cd0f 100644
--- a/fs/xfs/scrub/newbt.c
+++ b/fs/xfs/scrub/newbt.c
@@ -71,7 +71,7 @@ xrep_newbt_estimate_slack(
 		free = sc->sa.pag->pagf_freeblks;
 		sz = xfs_ag_block_count(sc->mp, pag_agno(sc->sa.pag));
 	} else {
-		free = xfs_sum_freecounter_raw(sc->mp, XC_FREE_BLOCKS);
+		free = xfs_sum_freecounter(sc->mp, XC_FREE_BLOCKS);
 		sz = sc->mp->m_sb.sb_dblocks;
 	}
 

[PATCH 05/12] xfs: don't queue rmap update twice when reaping a fork

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM noticed that xrep_reap_bmapi_iter calls xfs_bmap_unmap_extent and
xfs_rmap_unmap_extent to remove a mapping from a file fork and its
reverse mapping.  However, xfs_bmap_del_extent_real also queues a
deferred rmap removal log item, which means that we incorrectly queue
two rmap removal operations.  Fix that by removing the extra call and
updating the comment to mention this subtlety that I forgot, having
written the code. :P

Cc: <stable@vger.kernel.org> # v6.10
Fixes: 5befb047b9f4de ("xfs: add the ability to reap entire inode forks")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/scrub/reap.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


diff --git a/fs/xfs/scrub/reap.c b/fs/xfs/scrub/reap.c
index 528f5ef033d608..9377d687d0cc55 100644
--- a/fs/xfs/scrub/reap.c
+++ b/fs/xfs/scrub/reap.c
@@ -1492,12 +1492,12 @@ xrep_reap_bmapi_iter(
 		/*
 		 * t0: Schedule removal of the mapping from the fork.  We use
 		 * deferred log intents in this function to control the exact
-		 * sequence of metadata updates.
+		 * sequence of metadata updates.  The BUI queues a RUI to
+		 * remove the reverse mapping.
 		 */
 		xfs_bmap_unmap_extent(sc->tp, rs->ip, rs->whichfork, imap);
 		xfs_trans_mod_dquot_byino(sc->tp, rs->ip, XFS_TRANS_DQ_BCOUNT,
 				-(int64_t)imap->br_blockcount);
-		xfs_rmap_unmap_extent(sc->tp, rs->ip, rs->whichfork, imap);
 		return 0;
 	}
 

[PATCH 06/12] xfs: only written file data blocks can be shared

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM noticed that xchk_refcountbt_rmap_check (and its rt equivalent)
will count any rmap owner towards the shared count.  However, the only
blocks that can be shared between xfs files are written file data
blocks; and the only blocks that can have single-refcount entries are
COW staging extents.  Fix the checking code.

Cc: <stable@vger.kernel.org> # v4.16
Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
---
 fs/xfs/scrub/refcount.c   |   12 ++++++++++++
 fs/xfs/scrub/rtrefcount.c |   12 ++++++++++++
 2 files changed, 24 insertions(+)


diff --git a/fs/xfs/scrub/refcount.c b/fs/xfs/scrub/refcount.c
index f8c51d8fbb3da5..a900d13c9e27c0 100644
--- a/fs/xfs/scrub/refcount.c
+++ b/fs/xfs/scrub/refcount.c
@@ -129,6 +129,18 @@ xchk_refcountbt_rmap_check(
 		return 0;
 	}
 
+	/*
+	 * The refcount btree should only have records for written file data
+	 * blocks or for COW staging blocks.
+	 */
+	if ((XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) &&
+	     rec->rm_owner != XFS_RMAP_OWN_COW) ||
+	    (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK |
+			      XFS_RMAP_UNWRITTEN))) {
+		xchk_btree_xref_set_corrupt(refchk->sc, cur, 0);
+		return 0;
+	}
+
 	if (rec->rm_startblock <= refchk->bno && rm_last >= rc_last) {
 		/*
 		 * The rmap overlaps the refcount record, so we can confirm
diff --git a/fs/xfs/scrub/rtrefcount.c b/fs/xfs/scrub/rtrefcount.c
index 3d916d71a135dc..00da8e98506d63 100644
--- a/fs/xfs/scrub/rtrefcount.c
+++ b/fs/xfs/scrub/rtrefcount.c
@@ -144,6 +144,18 @@ xchk_rtrefcountbt_rmap_check(
 		return 0;
 	}
 
+	/*
+	 * The refcount btree should only have records for written file data
+	 * blocks or for COW staging blocks.
+	 */
+	if ((XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) &&
+	     rec->rm_owner != XFS_RMAP_OWN_COW) ||
+	    (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK |
+			      XFS_RMAP_UNWRITTEN))) {
+		xchk_btree_xref_set_corrupt(refchk->sc, cur, 0);
+		return 0;
+	}
+
 	if (rec->rm_startblock <= refchk->bno && rm_last >= rc_last) {
 		/*
 		 * The rmap overlaps the refcount record, so we can confirm

[PATCH 07/12] xfs: check for fragments when full-extent sharing matches

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM noticed that xchk_refcountbt_process_rmap_fragments returns early
if there are enough rmap records that overlap the space referenced by a
refcountbt record to match the refcount in that refcountbt record.
Unfortunately, it never checks the fragment list in this case, so it
won't find the discrepancy between the rmap and refcount btrees.

Cc: <stable@vger.kernel.org> # v4.16
Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/scrub/refcount.c   |    5 ++++-
 fs/xfs/scrub/rtrefcount.c |    5 ++++-
 2 files changed, 8 insertions(+), 2 deletions(-)


diff --git a/fs/xfs/scrub/refcount.c b/fs/xfs/scrub/refcount.c
index a900d13c9e27c0..883c273cb9883f 100644
--- a/fs/xfs/scrub/refcount.c
+++ b/fs/xfs/scrub/refcount.c
@@ -185,8 +185,11 @@ xchk_refcountbt_process_rmap_fragments(
 	xfs_nlink_t			target_nr;
 
 	target_nr = refchk->refcount - refchk->seen;
-	if (target_nr == 0)
+	if (target_nr == 0) {
+		if (!list_empty(&refchk->fragments))
+			refchk->seen = 0;
 		return;
+	}
 
 	/*
 	 * There are (refchk->rc.rc_refcount - refchk->nr refcount)
diff --git a/fs/xfs/scrub/rtrefcount.c b/fs/xfs/scrub/rtrefcount.c
index 00da8e98506d63..c312096e410561 100644
--- a/fs/xfs/scrub/rtrefcount.c
+++ b/fs/xfs/scrub/rtrefcount.c
@@ -200,8 +200,11 @@ xchk_rtrefcountbt_process_rmap_fragments(
 	xfs_nlink_t			target_nr;
 
 	target_nr = refchk->refcount - refchk->seen;
-	if (target_nr == 0)
+	if (target_nr == 0) {
+		if (!list_empty(&refchk->fragments))
+			refchk->seen = 0;
 		return;
+	}
 
 	/*
 	 * There are (refchk->rc.rc_refcount - refchk->nr refcount)

[PATCH 08/12] xfs: don't clear COWEXTSIZE on directories on reflink filesystems

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM noticed that xrep_dinode_flags clears the COWEXTSIZE flag
unnecessarily on directories on reflink filesystems.  Directories just
pass the hint along to new children, so it's valid to leave the flag
set.

Cc: <stable@vger.kernel.org> # v6.8
Fixes: 2d295fe65776d1 ("xfs: repair inode records")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/scrub/inode_repair.c |    2 ++
 1 file changed, 2 insertions(+)


diff --git a/fs/xfs/scrub/inode_repair.c b/fs/xfs/scrub/inode_repair.c
index 89cbf599795b2f..4b719ad64ace8c 100644
--- a/fs/xfs/scrub/inode_repair.c
+++ b/fs/xfs/scrub/inode_repair.c
@@ -565,6 +565,8 @@ xrep_dinode_flags(
 	 */
 	if (xfs_has_reflink(mp) && S_ISREG(mode))
 		flags2 |= XFS_DIFLAG2_REFLINK;
+	else if (xfs_has_reflink(mp) && S_ISDIR(mode))
+		flags2 &= ~XFS_DIFLAG2_REFLINK;
 	else
 		flags2 &= ~(XFS_DIFLAG2_REFLINK | XFS_DIFLAG2_COWEXTSIZE);
 	if (!xfs_has_bigtime(mp))

[PATCH 09/12] xfs: clear set[ug]id mode bits when zapping attr fork

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM observes that zapping a file's attr fork could result in ACLs
being removed from the file.  Because we have no idea what we're
deleting, we should clear the setuid and setgid bits in addition to the
access mode bits so that nobody can access the file.

Cc: <stable@vger.kernel.org> # v6.8
Fixes: e744cef2060559 ("xfs: zap broken inode forks")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/scrub/inode_repair.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)


diff --git a/fs/xfs/scrub/inode_repair.c b/fs/xfs/scrub/inode_repair.c
index 4b719ad64ace8c..25e71e7d472f36 100644
--- a/fs/xfs/scrub/inode_repair.c
+++ b/fs/xfs/scrub/inode_repair.c
@@ -1313,7 +1313,12 @@ xrep_dinode_zap_afork(
 	 */
 	if (dip->di_format != XFS_DINODE_FMT_BTREE)
 		dip->di_forkoff = 0;
-	dip->di_mode = cpu_to_be16(mode & ~0777);
+
+	/*
+	 * Zapping the attr fork could remove ACLs, so we clear suid/sgid and
+	 * all access mode bits.
+	 */
+	dip->di_mode = cpu_to_be16(mode & ~(S_ISUID | S_ISGID | 0777));
 	dip->di_uid = 0;
 	dip->di_gid = 0;
 }

[PATCH 10/12] xfs: opportunistically skip btree block checks

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM notices that both callers of xchk_btree_get_block will return
early if *pblock is NULL after a successful return.  However,
xchk_btree_get_block itself can return 0 after flagging a corruption.
There's no point in continuing after we've found a corruption, so null
the pointer out.

Cc: <stable@vger.kernel.org> # v4.15
Fixes: cc3e0948d2686f ("xfs: scrub the shape of a metadata btree")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
---
 fs/xfs/scrub/btree.c |    8 ++++++++
 1 file changed, 8 insertions(+)


diff --git a/fs/xfs/scrub/btree.c b/fs/xfs/scrub/btree.c
index 786b1e7c4dc37f..17bd8505be0411 100644
--- a/fs/xfs/scrub/btree.c
+++ b/fs/xfs/scrub/btree.c
@@ -602,6 +602,14 @@ xchk_btree_get_block(
 	xfs_btree_get_block(bs->cur, level, pbp);
 	if (__xfs_btree_check_block(bs->cur, *pblock, level, *pbp)) {
 		xchk_btree_set_corrupt(bs->sc, bs->cur, level);
+		/*
+		 * The btree block fails basic checks, so we know it's corrupt.
+		 * There's no need to continue looking for corruptions, so we
+		 * null out pblock.  If *pbp is non-null then it's also
+		 * attached to the transaction so we won't leak it despite the
+		 * 0 return code.
+		 */
+		*pblock = NULL;
 		return 0;
 	}
 	if (*pbp)

[PATCH 11/12] xfs: always report scrub errors in tracepoints

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM complains that the error processing functions in scrub will
sometimes zero out *error before recording a tracepoint.  This makes
diagnosing problems harder, so let's fix that.

Cc: <stable@vger.kernel.org> # v4.15
Fixes: 4700d22980d459 ("xfs: create helpers to record and deal with scrub problems")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/scrub/btree.c   |    8 +++++++-
 fs/xfs/scrub/common.c  |    7 +++++--
 fs/xfs/scrub/dabtree.c |    6 +++++-
 3 files changed, 17 insertions(+), 4 deletions(-)


diff --git a/fs/xfs/scrub/btree.c b/fs/xfs/scrub/btree.c
index 17bd8505be0411..43a7ea7308eea9 100644
--- a/fs/xfs/scrub/btree.c
+++ b/fs/xfs/scrub/btree.c
@@ -46,8 +46,14 @@ __xchk_btree_process_error(
 	case -ENODATA:
 		/* Note the badness but don't abort. */
 		sc->sm->sm_flags |= errflag;
+		if (cur->bc_ops->type == XFS_BTREE_TYPE_INODE)
+			trace_xchk_ifork_btree_op_error(sc, cur, level,
+					*error, ret_ip);
+		else
+			trace_xchk_btree_op_error(sc, cur, level,
+					*error, ret_ip);
 		*error = 0;
-		fallthrough;
+		break;
 	default:
 		if (cur->bc_ops->type == XFS_BTREE_TYPE_INODE)
 			trace_xchk_ifork_btree_op_error(sc, cur, level,
diff --git a/fs/xfs/scrub/common.c b/fs/xfs/scrub/common.c
index e5233e31abb750..a61895872072d1 100644
--- a/fs/xfs/scrub/common.c
+++ b/fs/xfs/scrub/common.c
@@ -107,8 +107,9 @@ __xchk_process_error(
 	case -ENODATA:
 		/* Note the badness but don't abort. */
 		sc->sm->sm_flags |= errflag;
+		trace_xchk_op_error(sc, agno, bno, *error, ret_ip);
 		*error = 0;
-		fallthrough;
+		break;
 	default:
 		trace_xchk_op_error(sc, agno, bno, *error, ret_ip);
 		break;
@@ -183,8 +184,10 @@ __xchk_fblock_process_error(
 	case -ENODATA:
 		/* Note the badness but don't abort. */
 		sc->sm->sm_flags |= errflag;
+		trace_xchk_file_op_error(sc, whichfork, offset, *error,
+				ret_ip);
 		*error = 0;
-		fallthrough;
+		break;
 	default:
 		trace_xchk_file_op_error(sc, whichfork, offset, *error,
 				ret_ip);
diff --git a/fs/xfs/scrub/dabtree.c b/fs/xfs/scrub/dabtree.c
index bbf6ece58828ca..02c8544d891861 100644
--- a/fs/xfs/scrub/dabtree.c
+++ b/fs/xfs/scrub/dabtree.c
@@ -49,8 +49,12 @@ xchk_da_process_error(
 	case -ENODATA:
 		/* Note the badness but don't abort. */
 		sc->sm->sm_flags |= XFS_SCRUB_OFLAG_CORRUPT;
+		trace_xchk_file_op_error(sc, ds->dargs.whichfork,
+				xfs_dir2_da_to_db(ds->dargs.geo,
+					ds->state->path.blk[level].blkno),
+				*error, __return_address);
 		*error = 0;
-		fallthrough;
+		break;
 	default:
 		trace_xchk_file_op_error(sc, ds->dargs.whichfork,
 				xfs_dir2_da_to_db(ds->dargs.geo,

[PATCH 12/12] xfs: don't scan across metadata/regular directory trees for dirents

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

LOLLM points out that the directory repair code should never scan files
in the regular directory tree when fixing a metadata directory and
vice-versa.  Amend the scan predicate to check this condition.

Cc: <stable@vger.kernel.org> # v6.13
Fixes: 4f3d4dd1b04b2b ("xfs: define the on-disk format for the metadir feature")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/scrub/dir_repair.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


diff --git a/fs/xfs/scrub/dir_repair.c b/fs/xfs/scrub/dir_repair.c
index 2cfcf1c35679ea..4a0b912b657696 100644
--- a/fs/xfs/scrub/dir_repair.c
+++ b/fs/xfs/scrub/dir_repair.c
@@ -1189,7 +1189,9 @@ xrep_dir_want_scan(
 	struct xrep_dir		*rd,
 	const struct xfs_inode	*ip)
 {
-	return ip != rd->sc->ip && !xrep_is_tempfile(ip);
+	return ip != rd->sc->ip &&
+	       xfs_is_metadir_inode(ip) == xfs_is_metadir_inode(rd->sc->ip) &&
+	       !xrep_is_tempfile(ip);
 }
 
 /*

Re: [PATCH 04/12] xfs: reduce new btree slack factor if free space is negative

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 10/12] xfs: opportunistically skip btree block checks

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 06/12] xfs: only written file data blocks can be shared

[Christoph Hellwig]

On Mon, Oct 12, 2026 at 11:06:46PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> LOLLM noticed that xchk_refcountbt_rmap_check (and its rt equivalent)
> will count any rmap owner towards the shared count.  However, the only
> blocks that can be shared between xfs files are written file data
> blocks; and the only blocks that can have single-refcount entries are
> COW staging extents.  Fix the checking code.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 06/12] xfs: only written file data blocks can be shared

[Carlos Maiolino]

On Mon, Oct 12, 2026 at 11:06:46PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> LOLLM noticed that xchk_refcountbt_rmap_check (and its rt equivalent)
> will count any rmap owner towards the shared count.  However, the only
> blocks that can be shared between xfs files are written file data
> blocks; and the only blocks that can have single-refcount entries are
> COW staging extents.  Fix the checking code.
> 
> Cc: <stable@vger.kernel.org> # v4.16
> Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt")
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> Assisted-by: LOLLM # finding obvious bugs

This patch conflicts with Eric's:

1d55a102780 xfs: re-use refcount scrub/repair code for rtrefcount

I'm just stripping off the rtrefcountbt part of this, the final result
is here:

commit 634b63baf05062988456a0bd5df2696c14ea2949
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Mon Oct 12 23:06:46 2026 -0700

    xfs: only written file data blocks can be shared



> ---
>  fs/xfs/scrub/refcount.c   |   12 ++++++++++++
>  fs/xfs/scrub/rtrefcount.c |   12 ++++++++++++
>  2 files changed, 24 insertions(+)
> 
> 
> diff --git a/fs/xfs/scrub/refcount.c b/fs/xfs/scrub/refcount.c
> index f8c51d8fbb3da5..a900d13c9e27c0 100644
> --- a/fs/xfs/scrub/refcount.c
> +++ b/fs/xfs/scrub/refcount.c
> @@ -129,6 +129,18 @@ xchk_refcountbt_rmap_check(
>  		return 0;
>  	}
>  
> +	/*
> +	 * The refcount btree should only have records for written file data
> +	 * blocks or for COW staging blocks.
> +	 */
> +	if ((XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) &&
> +	     rec->rm_owner != XFS_RMAP_OWN_COW) ||
> +	    (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK |
> +			      XFS_RMAP_UNWRITTEN))) {
> +		xchk_btree_xref_set_corrupt(refchk->sc, cur, 0);
> +		return 0;
> +	}
> +
>  	if (rec->rm_startblock <= refchk->bno && rm_last >= rc_last) {
>  		/*
>  		 * The rmap overlaps the refcount record, so we can confirm
> diff --git a/fs/xfs/scrub/rtrefcount.c b/fs/xfs/scrub/rtrefcount.c
> index 3d916d71a135dc..00da8e98506d63 100644
> --- a/fs/xfs/scrub/rtrefcount.c
> +++ b/fs/xfs/scrub/rtrefcount.c
> @@ -144,6 +144,18 @@ xchk_rtrefcountbt_rmap_check(
>  		return 0;
>  	}
>  
> +	/*
> +	 * The refcount btree should only have records for written file data
> +	 * blocks or for COW staging blocks.
> +	 */
> +	if ((XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) &&
> +	     rec->rm_owner != XFS_RMAP_OWN_COW) ||
> +	    (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK |
> +			      XFS_RMAP_UNWRITTEN))) {
> +		xchk_btree_xref_set_corrupt(refchk->sc, cur, 0);
> +		return 0;
> +	}
> +
>  	if (rec->rm_startblock <= refchk->bno && rm_last >= rc_last) {
>  		/*
>  		 * The rmap overlaps the refcount record, so we can confirm
> 
> 

Re: [PATCH 07/12] xfs: check for fragments when full-extent sharing matches

[Carlos Maiolino]

On Mon, Oct 12, 2026 at 11:07:01PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> LOLLM noticed that xchk_refcountbt_process_rmap_fragments returns early
> if there are enough rmap records that overlap the space referenced by a
> refcountbt record to match the refcount in that refcountbt record.
> Unfortunately, it never checks the fragment list in this case, so it
> won't find the discrepancy between the rmap and refcount btrees.
> 
> Cc: <stable@vger.kernel.org> # v4.16
> Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt")
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> Assisted-by: LOLLM # finding obvious bugs
> Reviewed-by: Christoph Hellwig <hch@lst.de>

Same thing for this patch... Final patch is:

commit 95e213c1ddb40dfb0a8178ed35c9f29992a320e1
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Mon Oct 12 23:07:01 2026 -0700

    xfs: check for fragments when full-extent sharing matches


> ---
>  fs/xfs/scrub/refcount.c   |    5 ++++-
>  fs/xfs/scrub/rtrefcount.c |    5 ++++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/fs/xfs/scrub/refcount.c b/fs/xfs/scrub/refcount.c
> index a900d13c9e27c0..883c273cb9883f 100644
> --- a/fs/xfs/scrub/refcount.c
> +++ b/fs/xfs/scrub/refcount.c
> @@ -185,8 +185,11 @@ xchk_refcountbt_process_rmap_fragments(
>  	xfs_nlink_t			target_nr;
>  
>  	target_nr = refchk->refcount - refchk->seen;
> -	if (target_nr == 0)
> +	if (target_nr == 0) {
> +		if (!list_empty(&refchk->fragments))
> +			refchk->seen = 0;
>  		return;
> +	}
>  
>  	/*
>  	 * There are (refchk->rc.rc_refcount - refchk->nr refcount)
> diff --git a/fs/xfs/scrub/rtrefcount.c b/fs/xfs/scrub/rtrefcount.c
> index 00da8e98506d63..c312096e410561 100644
> --- a/fs/xfs/scrub/rtrefcount.c
> +++ b/fs/xfs/scrub/rtrefcount.c
> @@ -200,8 +200,11 @@ xchk_rtrefcountbt_process_rmap_fragments(
>  	xfs_nlink_t			target_nr;
>  
>  	target_nr = refchk->refcount - refchk->seen;
> -	if (target_nr == 0)
> +	if (target_nr == 0) {
> +		if (!list_empty(&refchk->fragments))
> +			refchk->seen = 0;
>  		return;
> +	}
>  
>  	/*
>  	 * There are (refchk->rc.rc_refcount - refchk->nr refcount)
> 

Re: [PATCHSET v2 1/2] xfs: LLM-inspired bug fixes, part 22

[Carlos Maiolino]

On Mon, 12 Oct 2026 23:05:16 -0700, Darrick J. Wong wrote:
> Here's a twenty-second batch of xfs fixes resulting from a LLaMma.  Mwa
> mwa mwa...
> 
> v2: fix issues pointed out by reviewers.
> 
> If you're going to start using this code, I strongly recommend pulling
> from my git trees, which are linked below.
> 
> [...]

Applied to for-next, thanks!

[01/12] xfs: don't overrun incore inode when cleaning attr forks
        commit: c28b4b48deac17749ed1ebe4289a4ba73541ddc6
[02/12] xfs: fix data fork block count check in xrep_inode_blockcounts
        commit: 147f9f8300cb284923e08bb8a7b32ba9681c45ed
[03/12] xfs: avoid oversized space allocations when regenerating metadata
        commit: ca12256b7f9820aafb361ac496f048d2d4a71c23
[04/12] xfs: reduce new btree slack factor if free space is negative
        commit: 80f13dc7225eec318da7499c7a562d7a34d25e6a
[05/12] xfs: don't queue rmap update twice when reaping a fork
        commit: 219ff8a734d8438e24eb346a847c9b1ad9b7ab5d
[06/12] xfs: only written file data blocks can be shared
        commit: 634b63baf05062988456a0bd5df2696c14ea2949
[07/12] xfs: check for fragments when full-extent sharing matches
        commit: 95e213c1ddb40dfb0a8178ed35c9f29992a320e1
[08/12] xfs: don't clear COWEXTSIZE on directories on reflink filesystems
        commit: 3978b1f3109dfd5c648442bb040f9abd58608226
[09/12] xfs: clear set[ug]id mode bits when zapping attr fork
        commit: eb20a959760c21e3547cd811d0d9b0b29df98959
[10/12] xfs: opportunistically skip btree block checks
        commit: 4ce244b234c251963fca6dff9de6edf26a209d08
[11/12] xfs: always report scrub errors in tracepoints
        commit: 1ccc8f553d885d49c1bfe141ea1f331511940b3a
[12/12] xfs: don't scan across metadata/regular directory trees for dirents
        commit: 03ce4ca43c00394364493865f417d646e252bac2

Best regards,
-- 
Carlos Maiolino <cem@kernel.org>

Re: [PATCH 06/12] xfs: only written file data blocks can be shared

[Darrick J. Wong]

On Wed, Oct 14, 2026 at 10:25:53AM +0200, Carlos Maiolino wrote:
> On Mon, Oct 12, 2026 at 11:06:46PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > LOLLM noticed that xchk_refcountbt_rmap_check (and its rt equivalent)
> > will count any rmap owner towards the shared count.  However, the only
> > blocks that can be shared between xfs files are written file data
> > blocks; and the only blocks that can have single-refcount entries are
> > COW staging extents.  Fix the checking code.
> > 
> > Cc: <stable@vger.kernel.org> # v4.16
> > Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt")
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > Assisted-by: LOLLM # finding obvious bugs
> 
> This patch conflicts with Eric's:
> 
> 1d55a102780 xfs: re-use refcount scrub/repair code for rtrefcount
> 
> I'm just stripping off the rtrefcountbt part of this, the final result
> is here:
> 
> commit 634b63baf05062988456a0bd5df2696c14ea2949
> Author: Darrick J. Wong <djwong@kernel.org>
> Date:   Mon Oct 12 23:06:46 2026 -0700
> 
>     xfs: only written file data blocks can be shared

Yep, that looks good to me!

--D

> 
> 
> > ---
> >  fs/xfs/scrub/refcount.c   |   12 ++++++++++++
> >  fs/xfs/scrub/rtrefcount.c |   12 ++++++++++++
> >  2 files changed, 24 insertions(+)
> > 
> > 
> > diff --git a/fs/xfs/scrub/refcount.c b/fs/xfs/scrub/refcount.c
> > index f8c51d8fbb3da5..a900d13c9e27c0 100644
> > --- a/fs/xfs/scrub/refcount.c
> > +++ b/fs/xfs/scrub/refcount.c
> > @@ -129,6 +129,18 @@ xchk_refcountbt_rmap_check(
> >  		return 0;
> >  	}
> >  
> > +	/*
> > +	 * The refcount btree should only have records for written file data
> > +	 * blocks or for COW staging blocks.
> > +	 */
> > +	if ((XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) &&
> > +	     rec->rm_owner != XFS_RMAP_OWN_COW) ||
> > +	    (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK |
> > +			      XFS_RMAP_UNWRITTEN))) {
> > +		xchk_btree_xref_set_corrupt(refchk->sc, cur, 0);
> > +		return 0;
> > +	}
> > +
> >  	if (rec->rm_startblock <= refchk->bno && rm_last >= rc_last) {
> >  		/*
> >  		 * The rmap overlaps the refcount record, so we can confirm
> > diff --git a/fs/xfs/scrub/rtrefcount.c b/fs/xfs/scrub/rtrefcount.c
> > index 3d916d71a135dc..00da8e98506d63 100644
> > --- a/fs/xfs/scrub/rtrefcount.c
> > +++ b/fs/xfs/scrub/rtrefcount.c
> > @@ -144,6 +144,18 @@ xchk_rtrefcountbt_rmap_check(
> >  		return 0;
> >  	}
> >  
> > +	/*
> > +	 * The refcount btree should only have records for written file data
> > +	 * blocks or for COW staging blocks.
> > +	 */
> > +	if ((XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) &&
> > +	     rec->rm_owner != XFS_RMAP_OWN_COW) ||
> > +	    (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK |
> > +			      XFS_RMAP_UNWRITTEN))) {
> > +		xchk_btree_xref_set_corrupt(refchk->sc, cur, 0);
> > +		return 0;
> > +	}
> > +
> >  	if (rec->rm_startblock <= refchk->bno && rm_last >= rc_last) {
> >  		/*
> >  		 * The rmap overlaps the refcount record, so we can confirm
> > 
> > 
> 

Re: [PATCH 07/12] xfs: check for fragments when full-extent sharing matches

[Darrick J. Wong]

On Wed, Oct 14, 2026 at 10:26:04AM +0200, Carlos Maiolino wrote:
> On Mon, Oct 12, 2026 at 11:07:01PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > LOLLM noticed that xchk_refcountbt_process_rmap_fragments returns early
> > if there are enough rmap records that overlap the space referenced by a
> > refcountbt record to match the refcount in that refcountbt record.
> > Unfortunately, it never checks the fragment list in this case, so it
> > won't find the discrepancy between the rmap and refcount btrees.
> > 
> > Cc: <stable@vger.kernel.org> # v4.16
> > Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt")
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > Assisted-by: LOLLM # finding obvious bugs
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> 
> Same thing for this patch... Final patch is:
> 
> commit 95e213c1ddb40dfb0a8178ed35c9f29992a320e1
> Author: Darrick J. Wong <djwong@kernel.org>
> Date:   Mon Oct 12 23:07:01 2026 -0700
> 
>     xfs: check for fragments when full-extent sharing matches

Also looks good.

--D

> 
> > ---
> >  fs/xfs/scrub/refcount.c   |    5 ++++-
> >  fs/xfs/scrub/rtrefcount.c |    5 ++++-
> >  2 files changed, 8 insertions(+), 2 deletions(-)
> > 
> > 
> > diff --git a/fs/xfs/scrub/refcount.c b/fs/xfs/scrub/refcount.c
> > index a900d13c9e27c0..883c273cb9883f 100644
> > --- a/fs/xfs/scrub/refcount.c
> > +++ b/fs/xfs/scrub/refcount.c
> > @@ -185,8 +185,11 @@ xchk_refcountbt_process_rmap_fragments(
> >  	xfs_nlink_t			target_nr;
> >  
> >  	target_nr = refchk->refcount - refchk->seen;
> > -	if (target_nr == 0)
> > +	if (target_nr == 0) {
> > +		if (!list_empty(&refchk->fragments))
> > +			refchk->seen = 0;
> >  		return;
> > +	}
> >  
> >  	/*
> >  	 * There are (refchk->rc.rc_refcount - refchk->nr refcount)
> > diff --git a/fs/xfs/scrub/rtrefcount.c b/fs/xfs/scrub/rtrefcount.c
> > index 00da8e98506d63..c312096e410561 100644
> > --- a/fs/xfs/scrub/rtrefcount.c
> > +++ b/fs/xfs/scrub/rtrefcount.c
> > @@ -200,8 +200,11 @@ xchk_rtrefcountbt_process_rmap_fragments(
> >  	xfs_nlink_t			target_nr;
> >  
> >  	target_nr = refchk->refcount - refchk->seen;
> > -	if (target_nr == 0)
> > +	if (target_nr == 0) {
> > +		if (!list_empty(&refchk->fragments))
> > +			refchk->seen = 0;
> >  		return;
> > +	}
> >  
> >  	/*
> >  	 * There are (refchk->rc.rc_refcount - refchk->nr refcount)
> > 
>