All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: djwong@kernel.org
Cc: linux-xfs@vger.kernel.org, hch@lst.de, dchinner@redhat.com,
	christian.brauner@ubuntu.com
Subject: [PATCH 3/3] xfs: force log and push AIL to clear pinned inodes when aborting mount
Date: Tue, 02 Mar 2021 14:28:34 -0800	[thread overview]
Message-ID: <161472411392.3421449.548910053179741704.stgit@magnolia> (raw)
In-Reply-To: <161472409643.3421449.2100229515469727212.stgit@magnolia>

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

If we allocate quota inodes in the process of mounting a filesystem but
then decide to abort the mount, it's possible that the quota inodes are
sitting around pinned by the log.  Now that inode reclaim relies on the
AIL to flush inodes, we have to force the log and push the AIL in
between releasing the quota inodes and kicking off reclaim to tear down
all the incore inodes.

This was originally found during a fuzz test of metadata directories
(xfs/1546), but the actual symptom was that reclaim hung up on the quota
inodes.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 fs/xfs/xfs_mount.c |   10 ++++++++++
 1 file changed, 10 insertions(+)


diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 52370d0a3f43..6f445b611663 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -1007,6 +1007,16 @@ xfs_mountfs(
 	xfs_irele(rip);
 	/* Clean out dquots that might be in memory after quotacheck. */
 	xfs_qm_unmount(mp);
+
+	/*
+	 * It's possible that we modified some inodes as part of setting up
+	 * quotas or initializing filesystem metadata.  These inodes could be
+	 * pinned in the log, so force the log and push the AIL to unpin them
+	 * so that we can reclaim them.
+	 */
+	xfs_log_force(mp, XFS_LOG_SYNC);
+	xfs_ail_push_all_sync(mp->m_ail);
+
 	/*
 	 * Cancel all delayed reclaim work and reclaim the inodes directly.
 	 * We have to do this /after/ rtunmount and qm_unmount because those


  parent reply	other threads:[~2021-03-03  3:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02 22:28 [PATCHSET 0/3] xfs: small fixes for 5.12 Darrick J. Wong
2021-03-02 22:28 ` [PATCH 1/3] xfs: fix quota accounting when a mount is idmapped Darrick J. Wong
2021-03-03  6:43   ` Christoph Hellwig
2021-03-03 14:44   ` Christian Brauner
2021-03-03 18:33     ` Darrick J. Wong
2021-03-03 19:09       ` Christian Brauner
2021-03-02 22:28 ` [PATCH 2/3] xfs: avoid buffer deadlocks in inumbers/bulkstat Darrick J. Wong
2021-03-03  6:45   ` Christoph Hellwig
2021-03-03 18:57     ` Darrick J. Wong
2021-03-02 22:28 ` Darrick J. Wong [this message]
2021-03-03  6:48   ` [PATCH 3/3] xfs: force log and push AIL to clear pinned inodes when aborting mount Christoph Hellwig
2021-03-03 19:02     ` Darrick J. Wong
2021-03-02 23:07 ` [PATCHSET 0/3] xfs: small fixes for 5.12 Christian Brauner

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=161472411392.3421449.548910053179741704.stgit@magnolia \
    --to=djwong@kernel.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=dchinner@redhat.com \
    --cc=hch@lst.de \
    --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 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.