6.3-stable patches

added patches:
	xfs-fix-livelock-in-delayed-allocation-at-enospc.patch

diff --git a/queue-6.3/series b/queue-6.3/series
index 25adc88ab1ec9e08e1bcc91f6992f37152d816ed..f4abf3f52bd1779cbf72ceaf6c9e27553301ac22 100644 (file)
--- a/queue-6.3/series
+++ b/queue-6.3/series
@@ -34,3 +34,4 @@ parisc-fix-flush_dcache_page-for-usage-from-irq-context.patch
 parisc-allow-to-reboot-machine-after-system-halt.patch
 parisc-enable-lockdep-support.patch
 parisc-handle-kprobes-breakpoints-only-in-kernel-context.patch
+xfs-fix-livelock-in-delayed-allocation-at-enospc.patch

diff --git a/queue-6.3/xfs-fix-livelock-in-delayed-allocation-at-enospc.patch b/queue-6.3/xfs-fix-livelock-in-delayed-allocation-at-enospc.patch
new file mode 100644 (file)
index 0000000..c29a415
--- /dev/null
+++ b/queue-6.3/xfs-fix-livelock-in-delayed-allocation-at-enospc.patch
@@ -0,0 +1,54 @@
+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
+
+From: Dave Chinner <dchinner@redhat.com>
+
+commit 9419092fb2630c30e4ffeb9ef61007ef0c61827a upstream.
+
+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>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/xfs/libxfs/xfs_bmap.c |    1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/fs/xfs/libxfs/xfs_bmap.c
++++ b/fs/xfs/libxfs/xfs_bmap.c
+@@ -3505,7 +3505,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;
+ }