All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catherine Hoang <catherine.hoang@oracle.com>
To: stable@vger.kernel.org
Cc: linux-xfs@vger.kernel.org
Subject: [PATCH 6.6 07/21] xfs: make sure maxlen is still congruent with prod when rounding down
Date: Thu,  8 Feb 2024 15:20:40 -0800	[thread overview]
Message-ID: <20240208232054.15778-8-catherine.hoang@oracle.com> (raw)
In-Reply-To: <20240208232054.15778-1-catherine.hoang@oracle.com>

From: "Darrick J. Wong" <djwong@kernel.org>

commit f6a2dae2a1f52ea23f649c02615d073beba4cc35 upstream.

In commit 2a6ca4baed62, we tried to fix an overflow problem in the
realtime allocator that was caused by an overly large maxlen value
causing xfs_rtcheck_range to run off the end of the realtime bitmap.
Unfortunately, there is a subtle bug here -- maxlen (and minlen) both
have to be aligned with @prod, but @prod can be larger than 1 if the
user has set an extent size hint on the file, and that extent size hint
is larger than the realtime extent size.

If the rt free space extents are not aligned to this file's extszhint
because other files without extent size hints allocated space (or the
number of rt extents is similarly not aligned), then it's possible that
maxlen after clamping to sb_rextents will no longer be aligned to prod.
The allocation will succeed just fine, but we still trip the assertion.

Fix the problem by reducing maxlen by any misalignment with prod.  While
we're at it, split the assertions into two so that we can tell which
value had the bad alignment.

Fixes: 2a6ca4baed62 ("xfs: make sure the rt allocator doesn't run off the end")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
Acked-by: Chandan Babu R <chandanbabu@kernel.org>
---
 fs/xfs/xfs_rtalloc.c | 31 ++++++++++++++++++++++++++-----
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c
index 31fd65b3aaa9..0e4e2df08aed 100644
--- a/fs/xfs/xfs_rtalloc.c
+++ b/fs/xfs/xfs_rtalloc.c
@@ -211,6 +211,23 @@ xfs_rtallocate_range(
 	return error;
 }
 
+/*
+ * Make sure we don't run off the end of the rt volume.  Be careful that
+ * adjusting maxlen downwards doesn't cause us to fail the alignment checks.
+ */
+static inline xfs_extlen_t
+xfs_rtallocate_clamp_len(
+	struct xfs_mount	*mp,
+	xfs_rtblock_t		startrtx,
+	xfs_extlen_t		rtxlen,
+	xfs_extlen_t		prod)
+{
+	xfs_extlen_t		ret;
+
+	ret = min(mp->m_sb.sb_rextents, startrtx + rtxlen) - startrtx;
+	return rounddown(ret, prod);
+}
+
 /*
  * Attempt to allocate an extent minlen<=len<=maxlen starting from
  * bitmap block bbno.  If we don't get maxlen then use prod to trim
@@ -248,7 +265,7 @@ xfs_rtallocate_extent_block(
 	     i <= end;
 	     i++) {
 		/* Make sure we don't scan off the end of the rt volume. */
-		maxlen = min(mp->m_sb.sb_rextents, i + maxlen) - i;
+		maxlen = xfs_rtallocate_clamp_len(mp, i, maxlen, prod);
 
 		/*
 		 * See if there's a free extent of maxlen starting at i.
@@ -355,7 +372,8 @@ xfs_rtallocate_extent_exact(
 	int		isfree;		/* extent is free */
 	xfs_rtblock_t	next;		/* next block to try (dummy) */
 
-	ASSERT(minlen % prod == 0 && maxlen % prod == 0);
+	ASSERT(minlen % prod == 0);
+	ASSERT(maxlen % prod == 0);
 	/*
 	 * Check if the range in question (for maxlen) is free.
 	 */
@@ -438,7 +456,9 @@ xfs_rtallocate_extent_near(
 	xfs_rtblock_t	n;		/* next block to try */
 	xfs_rtblock_t	r;		/* result block */
 
-	ASSERT(minlen % prod == 0 && maxlen % prod == 0);
+	ASSERT(minlen % prod == 0);
+	ASSERT(maxlen % prod == 0);
+
 	/*
 	 * If the block number given is off the end, silently set it to
 	 * the last block.
@@ -447,7 +467,7 @@ xfs_rtallocate_extent_near(
 		bno = mp->m_sb.sb_rextents - 1;
 
 	/* Make sure we don't run off the end of the rt volume. */
-	maxlen = min(mp->m_sb.sb_rextents, bno + maxlen) - bno;
+	maxlen = xfs_rtallocate_clamp_len(mp, bno, maxlen, prod);
 	if (maxlen < minlen) {
 		*rtblock = NULLRTBLOCK;
 		return 0;
@@ -638,7 +658,8 @@ xfs_rtallocate_extent_size(
 	xfs_rtblock_t	r;		/* result block number */
 	xfs_suminfo_t	sum;		/* summary information for extents */
 
-	ASSERT(minlen % prod == 0 && maxlen % prod == 0);
+	ASSERT(minlen % prod == 0);
+	ASSERT(maxlen % prod == 0);
 	ASSERT(maxlen != 0);
 
 	/*
-- 
2.39.3


  parent reply	other threads:[~2024-02-08 23:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08 23:20 [PATCH 6.6 00/21] xfs backports for 6.6.y (from v6.7) Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 01/21] MAINTAINERS: add Catherine as xfs maintainer for 6.6.y Catherine Hoang
2024-02-08 23:40   ` kernel test robot
2024-02-08 23:20 ` [PATCH 6.6 02/21] xfs: bump max fsgeom struct version Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 03/21] xfs: hoist freeing of rt data fork extent mappings Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 04/21] xfs: prevent rt growfs when quota is enabled Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 05/21] xfs: rt stubs should return negative errnos when rt disabled Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 06/21] xfs: fix units conversion error in xfs_bmap_del_extent_delay Catherine Hoang
2024-02-08 23:20 ` Catherine Hoang [this message]
2024-02-08 23:20 ` [PATCH 6.6 08/21] xfs: introduce protection for drop nlink Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 09/21] xfs: handle nimaps=0 from xfs_bmapi_write in xfs_alloc_file_space Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 10/21] xfs: allow read IO and FICLONE to run concurrently Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 11/21] xfs: factor out xfs_defer_pending_abort Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 12/21] xfs: abort intent items when recovery intents fail Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 13/21] xfs: only remap the written blocks in xfs_reflink_end_cow_extent Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 14/21] xfs: up(ic_sema) if flushing data device fails Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 15/21] xfs: fix internal error from AGFL exhaustion Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 16/21] xfs: fix again select in kconfig XFS_ONLINE_SCRUB_STATS Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 17/21] xfs: inode recovery does not validate the recovered inode Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 18/21] xfs: clean up dqblk extraction Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 19/21] xfs: dquot recovery does not validate the recovered dquot Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 20/21] xfs: clean up FS_XFLAG_REALTIME handling in xfs_ioctl_setattr_xflags Catherine Hoang
2024-02-08 23:20 ` [PATCH 6.6 21/21] xfs: respect the stable writes flag on the RT device Catherine Hoang
2024-02-09 18:44 ` [PATCH 6.6 00/21] xfs backports for 6.6.y (from v6.7) Sasha Levin

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=20240208232054.15778-8-catherine.hoang@oracle.com \
    --to=catherine.hoang@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@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.