linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH 3/4] xfs: drain the buffer LRU on mount
Date: Mon, 23 Oct 2017 10:46:45 -0400	[thread overview]
Message-ID: <20171023144646.50107-4-bfoster@redhat.com> (raw)
In-Reply-To: <20171023144646.50107-1-bfoster@redhat.com>

Log recovery of v4 filesystems does not use buffer verifiers because
log recovery historically can result in transient buffer corruption
when target buffers might be ahead of the log after a crash. v5
filesystems work around this problem with metadata LSN ordering.

While the log recovery behavior is necessary on v4 supers, it
currently can result in leaving buffers around in the LRU without
verifiers attached for a significant amount of time. This can lead
to use of unverified buffers while the filesystem is in active use,
long after recovery has completed.

To address this problem and provide a more consistent clean,
post-mount buffer cache state, update the log mount sequence to
unconditionally drain all buffers from the LRU as a final step.

Reported-by: Darrick Wong <darrick.wong@oracle.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
 fs/xfs/xfs_log.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
index dc95a49..e282fd8 100644
--- a/fs/xfs/xfs_log.c
+++ b/fs/xfs/xfs_log.c
@@ -744,6 +744,7 @@ xfs_log_mount_finish(
 {
 	int	error = 0;
 	bool	readonly = (mp->m_flags & XFS_MOUNT_RDONLY);
+	bool	recovered = mp->m_log->l_flags & XLOG_RECOVERY_NEEDED;
 
 	if (mp->m_flags & XFS_MOUNT_NORECOVERY) {
 		ASSERT(mp->m_flags & XFS_MOUNT_RDONLY);
@@ -780,6 +781,18 @@ xfs_log_mount_finish(
 	mp->m_super->s_flags &= ~MS_ACTIVE;
 	evict_inodes(mp->m_super);
 
+	/*
+	 * Drain the buffer LRU after log recovery. This is required for v4
+	 * filesystems to avoid leaving around buffers with NULL verifier ops,
+	 * but we do it unconditionally to make sure we're always in a clean
+	 * cache state after mount.
+	 */
+	if (recovered) {
+		xfs_log_force(mp, XFS_LOG_SYNC);
+		xfs_ail_push_all_sync(mp->m_ail);
+	}
+	xfs_wait_buftarg(mp->m_ddev_targp);
+
 	if (readonly)
 		mp->m_flags |= XFS_MOUNT_RDONLY;
 
-- 
2.9.5


  parent reply	other threads:[~2017-10-23 14:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-23 14:46 [PATCH 0/4] xfs: miscellaneous log recovery fixes Brian Foster
2017-10-23 14:46 ` [PATCH 1/4] xfs: sanity check log record range parameters Brian Foster
2017-10-23 23:49   ` Darrick J. Wong
2017-10-24 11:30     ` Brian Foster
2017-10-25  5:09       ` Darrick J. Wong
2017-10-23 14:46 ` [PATCH 2/4] xfs: fix log block underflow during recovery cycle verification Brian Foster
2017-10-23 23:50   ` Darrick J. Wong
2017-10-23 14:46 ` Brian Foster [this message]
2017-10-23 16:39   ` [PATCH 3/4] xfs: drain the buffer LRU on mount Darrick J. Wong
2017-10-23 16:54     ` Brian Foster
2017-10-24  0:23       ` Darrick J. Wong
2017-10-24 14:06         ` Brian Foster
2017-10-24 19:47           ` Brian Foster
2017-10-23 14:46 ` [PATCH RFC 4/4] xfs: enforce a maximum total iclog buffer size Brian Foster

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=20171023144646.50107-4-bfoster@redhat.com \
    --to=bfoster@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).