All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chandan Babu R <chandan.babu@oracle.com>
To: linux-xfs@vger.kernel.org
Cc: Chandan Babu R <chandan.babu@oracle.com>,
	djwong@kernel.org, david@fromorbit.com
Subject: [PATCH V8 15/19] xfs: Directory's data fork extent counter can never overflow
Date: Mon, 21 Mar 2022 10:47:46 +0530	[thread overview]
Message-ID: <20220321051750.400056-16-chandan.babu@oracle.com> (raw)
In-Reply-To: <20220321051750.400056-1-chandan.babu@oracle.com>

The maximum file size that can be represented by the data fork extent counter
in the worst case occurs when all extents are 1 block in length and each block
is 1KB in size.

With XFS_MAX_EXTCNT_DATA_FORK_SMALL representing maximum extent count and with
1KB sized blocks, a file can reach upto,
(2^31) * 1KB = 2TB

This is much larger than the theoretical maximum size of a directory
i.e. 32GB * 3 = 96GB.

Since a directory's inode can never overflow its data fork extent counter,
this commit replaces checking the return value of
xfs_iext_count_may_overflow() with calls to ASSERT(error == 0).

Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
---
 fs/xfs/libxfs/xfs_bmap.c | 19 +++++++++----------
 fs/xfs/xfs_inode.c       | 32 ++++++++++++++++++++++++++++++++
 fs/xfs/xfs_symlink.c     |  8 ++++++++
 3 files changed, 49 insertions(+), 10 deletions(-)

diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
index 1254d4d4821e..5a089674c666 100644
--- a/fs/xfs/libxfs/xfs_bmap.c
+++ b/fs/xfs/libxfs/xfs_bmap.c
@@ -5148,24 +5148,23 @@ xfs_bmap_del_extent_real(
 		 */
 
 		/*
-		 * For directories, -ENOSPC is returned since a directory entry
-		 * remove operation must not fail due to low extent count
-		 * availability. -ENOSPC will be handled by higher layers of XFS
+		 * Extent count overflow during directory entry remove/rename
+		 * operation ideally should result in -ENOSPC being returned.
+		 * This error will eventually be handled by higher layers of XFS
 		 * by letting the corresponding empty Data/Free blocks to linger
 		 * until a future remove operation. Dabtree blocks would be
 		 * swapped with the last block in the leaf space and then the
 		 * new last block will be unmapped.
 		 *
-		 * The above logic also applies to the source directory entry of
-		 * a rename operation.
+		 * However, a directory inode can never overflow its data fork
+		 * extent counter because of reasons provided in the definition
+		 * of xfs_create().
 		 */
 		error = xfs_iext_count_may_overflow(ip, whichfork, 1);
-		if (error) {
-			ASSERT(S_ISDIR(VFS_I(ip)->i_mode) &&
-				whichfork == XFS_DATA_FORK);
-			error = -ENOSPC;
+		ASSERT(XFS_TEST_ERROR(false, ip->i_mount,
+				XFS_ERRTAG_REDUCE_MAX_IEXTENTS) || error == 0);
+		if (error)
 			goto done;
-		}
 
 		old = got;
 
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 6810c4feaa45..6016013658ff 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -1023,8 +1023,25 @@ xfs_create(
 	xfs_ilock(dp, XFS_ILOCK_EXCL | XFS_ILOCK_PARENT);
 	unlock_dp_on_error = true;
 
+	/*
+	 * The maximum file size that can be represented by the data fork extent
+	 * counter in the worst case occurs when all extents are 1 block in
+	 * length and each block is 1KB in size.
+	 *
+	 * With XFS_MAX_EXTCNT_DATA_FORK_SMALL representing maximum extent count
+	 * and with 1KB sized blocks, a file can reach upto,
+	 * 1KB * (2^31) = 2TB
+	 *
+	 * This is much larger than the theoretical maximum size of a directory
+	 * i.e. 32GB * 3 = 96GB.
+	 *
+	 * Hence, a directory inode can never overflow its data fork extent
+	 * counter.
+	 */
 	error = xfs_iext_count_may_overflow(dp, XFS_DATA_FORK,
 			XFS_IEXT_DIR_MANIP_CNT(mp));
+	ASSERT(XFS_TEST_ERROR(false, dp->i_mount,
+			XFS_ERRTAG_REDUCE_MAX_IEXTENTS) || error == 0);
 	if (error)
 		goto out_trans_cancel;
 
@@ -1249,8 +1266,15 @@ xfs_link(
 	xfs_trans_ijoin(tp, sip, XFS_ILOCK_EXCL);
 	xfs_trans_ijoin(tp, tdp, XFS_ILOCK_EXCL);
 
+	/*
+	 * Please refer to the comment in xfs_create() for an explaination of
+	 * why a directory inode cannot have its data fork extent counter to
+	 * overflow.
+	 */
 	error = xfs_iext_count_may_overflow(tdp, XFS_DATA_FORK,
 			XFS_IEXT_DIR_MANIP_CNT(mp));
+	ASSERT(XFS_TEST_ERROR(false, tdp->i_mount,
+			XFS_ERRTAG_REDUCE_MAX_IEXTENTS) || error == 0);
 	if (error)
 		goto error_return;
 
@@ -3232,9 +3256,17 @@ xfs_rename(
 			if (error)
 				goto out_trans_cancel;
 		} else {
+			/*
+			 * Please refer to the comment in xfs_create() for an
+			 * explaination of why a directory inode cannot have its
+			 * data fork extent counter to overflow.
+			 */
 			error = xfs_iext_count_may_overflow(target_dp,
 					XFS_DATA_FORK,
 					XFS_IEXT_DIR_MANIP_CNT(mp));
+			ASSERT(XFS_TEST_ERROR(false, target_dp->i_mount,
+					XFS_ERRTAG_REDUCE_MAX_IEXTENTS) ||
+			       error == 0);
 			if (error)
 				goto out_trans_cancel;
 		}
diff --git a/fs/xfs/xfs_symlink.c b/fs/xfs/xfs_symlink.c
index affbedf78160..0e5acb00c59f 100644
--- a/fs/xfs/xfs_symlink.c
+++ b/fs/xfs/xfs_symlink.c
@@ -23,6 +23,7 @@
 #include "xfs_trans.h"
 #include "xfs_ialloc.h"
 #include "xfs_error.h"
+#include "xfs_errortag.h"
 
 /* ----- Kernel only functions below ----- */
 int
@@ -226,8 +227,15 @@ xfs_symlink(
 		goto out_trans_cancel;
 	}
 
+	/*
+	 * Please refer to the comment in xfs_create() for an explaination of
+	 * why a directory inode cannot have its data fork extent counter to
+	 * overflow.
+	 */
 	error = xfs_iext_count_may_overflow(dp, XFS_DATA_FORK,
 			XFS_IEXT_DIR_MANIP_CNT(mp));
+	ASSERT(XFS_TEST_ERROR(false, dp->i_mount,
+			XFS_ERRTAG_REDUCE_MAX_IEXTENTS) || error == 0);
 	if (error)
 		goto out_trans_cancel;
 
-- 
2.30.2


  parent reply	other threads:[~2022-03-21  5:19 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21  5:17 [PATCH V8 00/19] xfs: Extend per-inode extent counters Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 01/19] xfs: Move extent count limits to xfs_format.h Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 02/19] xfs: Define max extent length based on on-disk format definition Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 03/19] xfs: Introduce xfs_iext_max_nextents() helper Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 04/19] xfs: Use xfs_extnum_t instead of basic data types Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 05/19] xfs: Introduce xfs_dfork_nextents() helper Chandan Babu R
2022-03-24 21:31   ` Dave Chinner
2022-03-21  5:17 ` [PATCH V8 06/19] xfs: Use basic types to define xfs_log_dinode's di_nextents and di_anextents Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 07/19] xfs: Promote xfs_extnum_t and xfs_aextnum_t to 64 and 32-bits respectively Chandan Babu R
2022-03-24 21:33   ` Dave Chinner
2022-03-21  5:17 ` [PATCH V8 08/19] xfs: Introduce XFS_SB_FEAT_INCOMPAT_NREXT64 and associated per-fs feature bit Chandan Babu R
2022-03-24 21:37   ` Dave Chinner
2022-03-24 21:40     ` Darrick J. Wong
2022-03-25  6:01       ` Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 09/19] xfs: Introduce XFS_FSOP_GEOM_FLAGS_NREXT64 Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 10/19] xfs: Introduce XFS_DIFLAG2_NREXT64 and associated helpers Chandan Babu R
2022-03-24 21:38   ` Dave Chinner
2022-03-21  5:17 ` [PATCH V8 11/19] xfs: Use uint64_t to count maximum blocks that can be used by BMBT Chandan Babu R
2022-03-24 21:42   ` Dave Chinner
2022-03-25  6:01     ` Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 12/19] xfs: Introduce macros to represent new maximum extent counts for data/attr forks Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 13/19] xfs: Replace numbered inode recovery error messages with descriptive ones Chandan Babu R
2022-03-24 21:47   ` Dave Chinner
2022-03-21  5:17 ` [PATCH V8 14/19] xfs: Introduce per-inode 64-bit extent counters Chandan Babu R
2022-03-24 21:53   ` Dave Chinner
2022-03-25  6:02     ` Chandan Babu R
2022-03-21  5:17 ` Chandan Babu R [this message]
2022-03-24 22:14   ` [PATCH V8 15/19] xfs: Directory's data fork extent counter can never overflow Dave Chinner
2022-03-25  6:02     ` Chandan Babu R
2022-03-25  6:37       ` Chandan Babu R
2022-03-29  5:22     ` Chandan Babu R
2022-03-29  6:23       ` Dave Chinner
2022-03-30  3:43         ` Darrick J. Wong
2022-03-30 15:39           ` Chandan Babu R
2022-03-30 15:52             ` Darrick J. Wong
2022-04-01  1:27           ` Dave Chinner
2022-04-01  7:46             ` Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 16/19] xfs: Conditionally upgrade existing inodes to use large extent counters Chandan Babu R
2022-03-24 22:28   ` Dave Chinner
2022-03-25  6:02     ` Chandan Babu R
2022-03-21  5:17 ` [PATCH V8 17/19] xfs: Decouple XFS_IBULK flags from XFS_IWALK flags Chandan Babu R
2022-03-24 22:28   ` Dave Chinner
2022-03-21  5:17 ` [PATCH V8 18/19] xfs: Enable bulkstat ioctl to support 64-bit per-inode extent counters Chandan Babu R
2022-03-24 22:33   ` Dave Chinner
2022-03-21  5:17 ` [PATCH V8 19/19] xfs: Add XFS_SB_FEAT_INCOMPAT_NREXT64 to the list of supported flags Chandan Babu R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220321051750.400056-16-chandan.babu@oracle.com \
    --to=chandan.babu@oracle.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.