Patch "xfs: handle nimaps=0 from xfs_bmapi_write in xfs_alloc_file_space" has been added to the 6.1-stable tree

This is a note to let you know that I've just added the patch titled

    xfs: handle nimaps=0 from xfs_bmapi_write in xfs_alloc_file_space

to the 6.1-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     xfs-handle-nimaps-0-from-xfs_bmapi_write-in-xfs_alloc_file_space.patch
and it can be found in the queue-6.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


From [email protected] Wed Jan 29 19:47:48 2025
From: Leah Rumancik <[email protected]>
Date: Wed, 29 Jan 2025 10:47:06 -0800
Subject: xfs: handle nimaps=0 from xfs_bmapi_write in xfs_alloc_file_space
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], Christoph Hellwig <[email protected]>, "Darrick J. Wong" <[email protected]>, Chandan Babu R <[email protected]>, Leah Rumancik <[email protected]>
Message-ID: <[email protected]>

From: Christoph Hellwig <[email protected]>

[ Upstream commit 35dc55b9e80cb9ec4bcb969302000b002b2ed850 ]

If xfs_bmapi_write finds a delalloc extent at the requested range, it
tries to convert the entire delalloc extent to a real allocation.

But if the allocator cannot find a single free extent large enough to
cover the start block of the requested range, xfs_bmapi_write will
return 0 but leave *nimaps set to 0.

In that case we simply need to keep looping with the same startoffset_fsb
so that one of the following allocations will eventually reach the
requested range.

Note that this could affect any caller of xfs_bmapi_write that covers
an existing delayed allocation.  As far as I can tell we do not have
any other such caller, though - the regular writeback path uses
xfs_bmapi_convert_delalloc to convert delayed allocations to real ones,
and direct I/O invalidates the page cache first.

Signed-off-by: Christoph Hellwig <[email protected]>
Reviewed-by: "Darrick J. Wong" <[email protected]>
Signed-off-by: Chandan Babu R <[email protected]>
Signed-off-by: Leah Rumancik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
 fs/xfs/xfs_bmap_util.c |   24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -780,12 +780,10 @@ xfs_alloc_file_space(
 {
 	xfs_mount_t		*mp = ip->i_mount;
 	xfs_off_t		count;
-	xfs_filblks_t		allocated_fsb;
 	xfs_filblks_t		allocatesize_fsb;
 	xfs_extlen_t		extsz, temp;
 	xfs_fileoff_t		startoffset_fsb;
 	xfs_fileoff_t		endoffset_fsb;
-	int			nimaps;
 	int			rt;
 	xfs_trans_t		*tp;
 	xfs_bmbt_irec_t		imaps[1], *imapp;
@@ -808,7 +806,6 @@ xfs_alloc_file_space(
 
 	count = len;
 	imapp = &imaps[0];
-	nimaps = 1;
 	startoffset_fsb	= XFS_B_TO_FSBT(mp, offset);
 	endoffset_fsb = XFS_B_TO_FSB(mp, offset + count);
 	allocatesize_fsb = endoffset_fsb - startoffset_fsb;
@@ -819,6 +816,7 @@ xfs_alloc_file_space(
 	while (allocatesize_fsb && !error) {
 		xfs_fileoff_t	s, e;
 		unsigned int	dblocks, rblocks, resblks;
+		int		nimaps = 1;
 
 		/*
 		 * Determine space reservations for data/realtime.
@@ -884,15 +882,19 @@ xfs_alloc_file_space(
 		if (error)
 			break;
 
-		allocated_fsb = imapp->br_blockcount;
-
-		if (nimaps == 0) {
-			error = -ENOSPC;
-			break;
+		/*
+		 * If the allocator cannot find a single free extent large
+		 * enough to cover the start block of the requested range,
+		 * xfs_bmapi_write will return 0 but leave *nimaps set to 0.
+		 *
+		 * In that case we simply need to keep looping with the same
+		 * startoffset_fsb so that one of the following allocations
+		 * will eventually reach the requested range.
+		 */
+		if (nimaps) {
+			startoffset_fsb += imapp->br_blockcount;
+			allocatesize_fsb -= imapp->br_blockcount;
 		}
-
-		startoffset_fsb += allocated_fsb;
-		allocatesize_fsb -= allocated_fsb;
 	}
 
 	return error;


Patches currently in stable-queue which might be from [email protected] are

queue-6.1/xfs-allow-read-io-and-ficlone-to-run-concurrently.patch
queue-6.1/xfs-hoist-freeing-of-rt-data-fork-extent-mappings.patch
queue-6.1/xfs-make-sure-maxlen-is-still-congruent-with-prod-when-rounding-down.patch
queue-6.1/xfs-only-remap-the-written-blocks-in-xfs_reflink_end_cow_extent.patch
queue-6.1/xfs-dquot-recovery-does-not-validate-the-recovered-dquot.patch
queue-6.1/xfs-clean-up-dqblk-extraction.patch
queue-6.1/xfs-abort-intent-items-when-recovery-intents-fail.patch
queue-6.1/xfs-up-ic_sema-if-flushing-data-device-fails.patch
queue-6.1/xfs-fix-internal-error-from-agfl-exhaustion.patch
queue-6.1/xfs-factor-out-xfs_defer_pending_abort.patch
queue-6.1/xfs-fix-units-conversion-error-in-xfs_bmap_del_extent_delay.patch
queue-6.1/xfs-bump-max-fsgeom-struct-version.patch
queue-6.1/xfs-handle-nimaps-0-from-xfs_bmapi_write-in-xfs_alloc_file_space.patch
queue-6.1/xfs-rt-stubs-should-return-negative-errnos-when-rt-disabled.patch
queue-6.1/xfs-clean-up-fs_xflag_realtime-handling-in-xfs_ioctl_setattr_xflags.patch
queue-6.1/xfs-respect-the-stable-writes-flag-on-the-rt-device.patch
queue-6.1/xfs-introduce-protection-for-drop-nlink.patch
queue-6.1/xfs-prevent-rt-growfs-when-quota-is-enabled.patch
queue-6.1/xfs-inode-recovery-does-not-validate-the-recovered-inode.patch