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
next prev 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