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 15/24] xfs: force all buffers to be written during btree bulk load
Date: Tue, 26 Mar 2024 17:12:24 -0700	[thread overview]
Message-ID: <20240327001233.51675-16-catherine.hoang@oracle.com> (raw)
In-Reply-To: <20240327001233.51675-1-catherine.hoang@oracle.com>

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

commit 13ae04d8d45227c2ba51e188daf9fc13d08a1b12 upstream.

While stress-testing online repair of btrees, I noticed periodic
assertion failures from the buffer cache about buffers with incorrect
DELWRI_Q state.  Looking further, I observed this race between the AIL
trying to write out a btree block and repair zapping a btree block after
the fact:

AIL:    Repair0:

pin buffer X
delwri_queue:
set DELWRI_Q
add to delwri list

        stale buf X:
        clear DELWRI_Q
        does not clear b_list
        free space X
        commit

delwri_submit   # oops

Worse yet, I discovered that running the same repair over and over in a
tight loop can result in a second race that cause data integrity
problems with the repair:

AIL:    Repair0:        Repair1:

pin buffer X
delwri_queue:
set DELWRI_Q
add to delwri list

        stale buf X:
        clear DELWRI_Q
        does not clear b_list
        free space X
        commit

                        find free space X
                        get buffer
                        rewrite buffer
                        delwri_queue:
                        set DELWRI_Q
                        already on a list, do not add
                        commit

                        BAD: committed tree root before all blocks written

delwri_submit   # too late now

I traced this to my own misunderstanding of how the delwri lists work,
particularly with regards to the AIL's buffer list.  If a buffer is
logged and committed, the buffer can end up on that AIL buffer list.  If
btree repairs are run twice in rapid succession, it's possible that the
first repair will invalidate the buffer and free it before the next time
the AIL wakes up.  Marking the buffer stale clears DELWRI_Q from the
buffer state without removing the buffer from its delwri list.  The
buffer doesn't know which list it's on, so it cannot know which lock to
take to protect the list for a removal.

If the second repair allocates the same block, it will then recycle the
buffer to start writing the new btree block.  Meanwhile, if the AIL
wakes up and walks the buffer list, it will ignore the buffer because it
can't lock it, and go back to sleep.

When the second repair calls delwri_queue to put the buffer on the
list of buffers to write before committing the new btree, it will set
DELWRI_Q again, but since the buffer hasn't been removed from the AIL's
buffer list, it won't add it to the bulkload buffer's list.

This is incorrect, because the bulkload caller relies on delwri_submit
to ensure that all the buffers have been sent to disk /before/
committing the new btree root pointer.  This ordering requirement is
required for data consistency.

Worse, the AIL won't clear DELWRI_Q from the buffer when it does finally
drop it, so the next thread to walk through the btree will trip over a
debug assertion on that flag.

To fix this, create a new function that waits for the buffer to be
removed from any other delwri lists before adding the buffer to the
caller's delwri list.  By waiting for the buffer to clear both the
delwri list and any potential delwri wait list, we can be sure that
repair will initiate writes of all buffers and report all write errors
back to userspace instead of committing the new structure.

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: Darrick J. Wong <djwong@kernel.org>
---
 fs/xfs/libxfs/xfs_btree_staging.c |  4 +--
 fs/xfs/xfs_buf.c                  | 44 ++++++++++++++++++++++++++++---
 fs/xfs/xfs_buf.h                  |  1 +
 3 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/fs/xfs/libxfs/xfs_btree_staging.c b/fs/xfs/libxfs/xfs_btree_staging.c
index dd75e208b543..29e3f8ccb185 100644
--- a/fs/xfs/libxfs/xfs_btree_staging.c
+++ b/fs/xfs/libxfs/xfs_btree_staging.c
@@ -342,9 +342,7 @@ xfs_btree_bload_drop_buf(
 	if (*bpp == NULL)
 		return;
 
-	if (!xfs_buf_delwri_queue(*bpp, buffers_list))
-		ASSERT(0);
-
+	xfs_buf_delwri_queue_here(*bpp, buffers_list);
 	xfs_buf_relse(*bpp);
 	*bpp = NULL;
 }
diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index c1ece4a08ff4..20c1d146af1d 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -2049,6 +2049,14 @@ xfs_alloc_buftarg(
 	return NULL;
 }
 
+static inline void
+xfs_buf_list_del(
+	struct xfs_buf		*bp)
+{
+	list_del_init(&bp->b_list);
+	wake_up_var(&bp->b_list);
+}
+
 /*
  * Cancel a delayed write list.
  *
@@ -2066,7 +2074,7 @@ xfs_buf_delwri_cancel(
 
 		xfs_buf_lock(bp);
 		bp->b_flags &= ~_XBF_DELWRI_Q;
-		list_del_init(&bp->b_list);
+		xfs_buf_list_del(bp);
 		xfs_buf_relse(bp);
 	}
 }
@@ -2119,6 +2127,34 @@ xfs_buf_delwri_queue(
 	return true;
 }
 
+/*
+ * Queue a buffer to this delwri list as part of a data integrity operation.
+ * If the buffer is on any other delwri list, we'll wait for that to clear
+ * so that the caller can submit the buffer for IO and wait for the result.
+ * Callers must ensure the buffer is not already on the list.
+ */
+void
+xfs_buf_delwri_queue_here(
+	struct xfs_buf		*bp,
+	struct list_head	*buffer_list)
+{
+	/*
+	 * We need this buffer to end up on the /caller's/ delwri list, not any
+	 * old list.  This can happen if the buffer is marked stale (which
+	 * clears DELWRI_Q) after the AIL queues the buffer to its list but
+	 * before the AIL has a chance to submit the list.
+	 */
+	while (!list_empty(&bp->b_list)) {
+		xfs_buf_unlock(bp);
+		wait_var_event(&bp->b_list, list_empty(&bp->b_list));
+		xfs_buf_lock(bp);
+	}
+
+	ASSERT(!(bp->b_flags & _XBF_DELWRI_Q));
+
+	xfs_buf_delwri_queue(bp, buffer_list);
+}
+
 /*
  * Compare function is more complex than it needs to be because
  * the return value is only 32 bits and we are doing comparisons
@@ -2181,7 +2217,7 @@ xfs_buf_delwri_submit_buffers(
 		 * reference and remove it from the list here.
 		 */
 		if (!(bp->b_flags & _XBF_DELWRI_Q)) {
-			list_del_init(&bp->b_list);
+			xfs_buf_list_del(bp);
 			xfs_buf_relse(bp);
 			continue;
 		}
@@ -2201,7 +2237,7 @@ xfs_buf_delwri_submit_buffers(
 			list_move_tail(&bp->b_list, wait_list);
 		} else {
 			bp->b_flags |= XBF_ASYNC;
-			list_del_init(&bp->b_list);
+			xfs_buf_list_del(bp);
 		}
 		__xfs_buf_submit(bp, false);
 	}
@@ -2255,7 +2291,7 @@ xfs_buf_delwri_submit(
 	while (!list_empty(&wait_list)) {
 		bp = list_first_entry(&wait_list, struct xfs_buf, b_list);
 
-		list_del_init(&bp->b_list);
+		xfs_buf_list_del(bp);
 
 		/*
 		 * Wait on the locked buffer, check for errors and unlock and
diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
index df8f47953bb4..5896b58c5f4d 100644
--- a/fs/xfs/xfs_buf.h
+++ b/fs/xfs/xfs_buf.h
@@ -318,6 +318,7 @@ extern void xfs_buf_stale(struct xfs_buf *bp);
 /* Delayed Write Buffer Routines */
 extern void xfs_buf_delwri_cancel(struct list_head *);
 extern bool xfs_buf_delwri_queue(struct xfs_buf *, struct list_head *);
+void xfs_buf_delwri_queue_here(struct xfs_buf *bp, struct list_head *bl);
 extern int xfs_buf_delwri_submit(struct list_head *);
 extern int xfs_buf_delwri_submit_nowait(struct list_head *);
 extern int xfs_buf_delwri_pushbuf(struct xfs_buf *, struct list_head *);
-- 
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 ` [PATCH 6.6 14/24] xfs: fix an off-by-one error in xreap_agextent_binval Catherine Hoang
2024-03-27  0:12 ` Catherine Hoang [this message]
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-16-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.