xfs: fix livelock in delayed allocation at ENOSPC6.3-7

Signed-off-by: Mike Pagano <mpagano@gentoo.org>

2 files changed, 60 insertions, 0 deletions

diff --git a/0000_README b/0000_README
index dfa966c1..447571a4 100644
--- a/0000_README
+++ b/0000_README
@@ -71,6 +71,10 @@ Patch:  1700_sparc-address-warray-bound-warnings.patch
 From:		https://github.com/KSPP/linux/issues/109
 Desc:		Address -Warray-bounds warnings 
 
+Patch:  1900_xfs-livelock-fix-in-delaye-alloc-at-ENOSPC.patch
+From:		https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
+Desc:		xfs: fix livelock in delayed allocation at ENOSPC
+
 Patch:  2000_BT-Check-key-sizes-only-if-Secure-Simple-Pairing-enabled.patch
 From:   https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@holtmann.org/raw
 Desc:   Bluetooth: Check key sizes only when Secure Simple Pairing is enabled. See bug #686758
diff --git a/1900_xfs-livelock-fix-in-delaye-alloc-at-ENOSPC.patch b/1900_xfs-livelock-fix-in-delaye-alloc-at-ENOSPC.patch
new file mode 100644
index 00000000..e1e5726b
--- /dev/null
+++ b/1900_xfs-livelock-fix-in-delaye-alloc-at-ENOSPC.patch
@@ -0,0 +1,56 @@
+From 9419092fb2630c30e4ffeb9ef61007ef0c61827a Mon Sep 17 00:00:00 2001
+From: Dave Chinner <dchinner@redhat.com>
+Date: Thu, 27 Apr 2023 09:02:11 +1000
+Subject: xfs: fix livelock in delayed allocation at ENOSPC
+
+On a filesystem with a non-zero stripe unit and a large sequential
+write, delayed allocation will set a minimum allocation length of
+the stripe unit. If allocation fails because there are no extents
+long enough for an aligned minlen allocation, it is supposed to
+fall back to unaligned allocation which allows single block extents
+to be allocated.
+
+When the allocator code was rewritting in the 6.3 cycle, this
+fallback was broken - the old code used args->fsbno as the both the
+allocation target and the allocation result, the new code passes the
+target as a separate parameter. The conversion didn't handle the
+aligned->unaligned fallback path correctly - it reset args->fsbno to
+the target fsbno on failure which broke allocation failure detection
+in the high level code and so it never fell back to unaligned
+allocations.
+
+This resulted in a loop in writeback trying to allocate an aligned
+block, getting a false positive success, trying to insert the result
+in the BMBT. This did nothing because the extent already was in the
+BMBT (merge results in an unchanged extent) and so it returned the
+prior extent to the conversion code as the current iomap.
+
+Because the iomap returned didn't cover the offset we tried to map,
+xfs_convert_blocks() then retries the allocation, which fails in the
+same way and now we have a livelock.
+
+Reported-and-tested-by: Brian Foster <bfoster@redhat.com>
+Fixes: 85843327094f ("xfs: factor xfs_bmap_btalloc()")
+Signed-off-by: Dave Chinner <dchinner@redhat.com>
+Reviewed-by: Darrick J. Wong <djwong@kernel.org>
+---
+ fs/xfs/libxfs/xfs_bmap.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+(limited to 'fs/xfs/libxfs/xfs_bmap.c')
+
+diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
+index 1a4e446194dd8..b512de0540d54 100644
+--- a/fs/xfs/libxfs/xfs_bmap.c
++++ b/fs/xfs/libxfs/xfs_bmap.c
+@@ -3540,7 +3540,6 @@ xfs_bmap_btalloc_at_eof(
+ 	 * original non-aligned state so the caller can proceed on allocation
+ 	 * failure as if this function was never called.
+ 	 */
+-	args->fsbno = ap->blkno;
+ 	args->alignment = 1;
+ 	return 0;
+ }
+-- 
+cgit 
+