FAILED: patch "[PATCH] xfs: flag excessive delalloc rt extents as corruption" failed to apply to 6.12-stable tree

The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
git checkout FETCH_HEAD
git cherry-pick -x 2b47be015a5e54f4a3d62afa636ba593de9b67f6
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026110458-culprit-afar-aadb@gregkh' --subject-prefix 'PATCH 6.12.y' 'HEAD^..'

Possible dependencies:

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 2b47be015a5e54f4a3d62afa636ba593de9b67f6 Mon Sep 17 00:00:00 2001
From: "Darrick J. Wong" <[email protected]>
Date: Sun, 4 Oct 2026 22:55:33 -0700
Subject: [PATCH] xfs: flag excessive delalloc rt extents as corruption

LOLLM observed that we should not allow repairs to proceed if the count of delayed-allocation realtime extents exceeds the number of free rt extents because we can't install negative numbers into the superblock. It's unclear how we could end up in that state in real life, but let's at least complain loudly about it if we ever encounter it.

index b3fb1b422765..eb1a095a0fa9 100644
@@ -609,6 +609,13 @@ xchk_fscounters(
 			try_again = true;
 	}
 
+	if (!xfs_has_zoned(mp) && fsc->frextents < fsc->frextents_delayed) {
+		if (fsc->frozen)
+			xchk_set_incomplete(sc);
+		else
+			try_again = true;
+	}
+
 	if (!xfs_has_zoned(mp) &&
 	    !xchk_fscount_within_range(sc, frextents,
 			&mp->m_free[XC_FREE_RTEXTENTS].count,

From: "Darrick J. Wong" <[email protected]>

[ Upstream commit 2b47be015a5e54f4a3d62afa636ba593de9b67f6 ]

LOLLM observed that we should not allow repairs to proceed if the count of delayed-allocation realtime extents exceeds the number of free rt extents because we can't install negative numbers into the superblock. It's unclear how we could end up in that state in real life, but let's at least complain loudly about it if we ever encounter it.

---
 fs/xfs/scrub/fscounters.c | 7 +++++++
 1 file changed, 7 insertions(+)

index 98634c668b56c..ac7e6329e46e8 100644
@@ -606,6 +606,13 @@ xchk_fscounters(
 			try_again = true;
 	}
 
+	if (fsc->frextents < fsc->frextents_delayed) {
+		if (fsc->frozen)
+			xchk_set_incomplete(sc);
+		else
+			try_again = true;
+	}
+
 	if (!xchk_fscount_within_range(sc, frextents, &mp->m_frextents,
 			fsc->frextents - fsc->frextents_delayed)) {
 		if (fsc->frozen)

2.53.0