Linux kernel -stable discussions
 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 14/24] xfs: fix an off-by-one error in xreap_agextent_binval
Date: Tue, 26 Mar 2024 17:12:23 -0700	[thread overview]
Message-ID: <20240327001233.51675-15-catherine.hoang@oracle.com> (raw)
In-Reply-To: <20240327001233.51675-1-catherine.hoang@oracle.com>

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

commit c0e37f07d2bd3c1ee3fb5a650da7d8673557ed16 upstream.

Overall, this function tries to find and invalidate all buffers for a
given extent of space on the data device.  The inner for loop in this
function tries to find all xfs_bufs for a given daddr.  The lengths of
all possible cached buffers range from 1 fsblock to the largest needed
to contain a 64k xattr value (~17fsb).  The scan is capped to avoid
looking at anything buffer going past the given extent.

Unfortunately, the loop continuation test is wrong -- max_fsbs is the
largest size we want to scan, not one past that.  Put another way, this
loop is actually 1-indexed, not 0-indexed.  Therefore, the continuation
test should use <=, not <.

As a result, online repairs of btree blocks fails to stale any buffers
for btrees that are being torn down, which causes later assertions in
the buffer cache when another thread creates a different-sized buffer.
This happens in xfs/709 when allocating an inode cluster buffer:

 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 3346128 at fs/xfs/xfs_message.c:104 assfail+0x3a/0x40 [xfs]
 CPU: 0 PID: 3346128 Comm: fsstress Not tainted 6.7.0-rc4-djwx #rc4
 RIP: 0010:assfail+0x3a/0x40 [xfs]
 Call Trace:
  <TASK>
  _xfs_buf_obj_cmp+0x4a/0x50
  xfs_buf_get_map+0x191/0xba0
  xfs_trans_get_buf_map+0x136/0x280
  xfs_ialloc_inode_init+0x186/0x340
  xfs_ialloc_ag_alloc+0x254/0x720
  xfs_dialloc+0x21f/0x870
  xfs_create_tmpfile+0x1a9/0x2f0
  xfs_rename+0x369/0xfd0
  xfs_vn_rename+0xfa/0x170
  vfs_rename+0x5fb/0xc30
  do_renameat2+0x52d/0x6e0
  __x64_sys_renameat2+0x4b/0x60
  do_syscall_64+0x3b/0xe0
  entry_SYSCALL_64_after_hwframe+0x46/0x4e

A later refactoring patch in the online repair series fixed this by
accident, which is why I didn't notice this until I started testing only
the patches that are likely to end up in 6.8.

Fixes: 1c7ce115e521 ("xfs: reap large AG metadata extents when possible")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
---
 fs/xfs/scrub/reap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/scrub/reap.c b/fs/xfs/scrub/reap.c
index 86a62420e02c..822f5adf7f7c 100644
--- a/fs/xfs/scrub/reap.c
+++ b/fs/xfs/scrub/reap.c
@@ -247,7 +247,7 @@ xreap_agextent_binval(
 		max_fsbs = min_t(xfs_agblock_t, agbno_next - bno,
 				xfs_attr3_rmt_blocks(mp, XFS_XATTR_SIZE_MAX));
 
-		for (fsbcount = 1; fsbcount < max_fsbs; fsbcount++) {
+		for (fsbcount = 1; fsbcount <= max_fsbs; fsbcount++) {
 			struct xfs_buf	*bp = NULL;
 			xfs_daddr_t	daddr;
 			int		error;
-- 
2.39.3


  parent reply	other threads:[~2024-03-27  0:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27  0:12 [PATCH 6.6 00/24] xfs backports for 6.6.y (from 6.8) Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 01/24] xfs: move the xfs_rtbitmap.c declarations to xfs_rtbitmap.h Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 02/24] xfs: convert rt bitmap extent lengths to xfs_rtbxlen_t Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 03/24] xfs: consider minlen sized extents in xfs_rtallocate_extent_block Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 04/24] xfs: don't leak recovered attri intent items Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 05/24] xfs: use xfs_defer_pending objects to recover " Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 06/24] xfs: pass the xfs_defer_pending object to iop_recover Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 07/24] xfs: transfer recovered intent item ownership in ->iop_recover Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 08/24] xfs: make rextslog computation consistent with mkfs Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 09/24] xfs: fix 32-bit truncation in xfs_compute_rextslog Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 10/24] xfs: don't allow overly small or large realtime volumes Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 11/24] xfs: make xchk_iget safer in the presence of corrupt inode btrees Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 12/24] xfs: remove unused fields from struct xbtree_ifakeroot Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 13/24] xfs: recompute growfsrtfree transaction reservation while growing rt volume Catherine Hoang
2024-03-27  0:12 ` Catherine Hoang [this message]
2024-03-27  0:12 ` [PATCH 6.6 15/24] xfs: force all buffers to be written during btree bulk load Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 16/24] xfs: add missing nrext64 inode flag check to scrub Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 17/24] xfs: initialise di_crc in xfs_log_dinode Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 18/24] xfs: short circuit xfs_growfs_data_private() if delta is zero Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 19/24] xfs: add lock protection when remove perag from radix tree Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 20/24] xfs: fix perag leak when growfs fails Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 21/24] xfs: ensure logflagsp is initialized in xfs_bmap_del_extent_real Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 22/24] xfs: update dir3 leaf block metadata after swap Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 23/24] xfs: reset XFS_ATTR_INCOMPLETE filter on node removal Catherine Hoang
2024-03-27  0:12 ` [PATCH 6.6 24/24] xfs: remove conditional building of rt geometry validator functions Catherine Hoang
2024-03-29  9:52 ` [PATCH 6.6 00/24] xfs backports for 6.6.y (from 6.8) Greg KH

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=20240327001233.51675-15-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox