diff mbox series

[3/3] xfs: force log and push AIL to clear pinned inodes when aborting mount

Message ID 161472411392.3421449.548910053179741704.stgit@magnolia (mailing list archive)
State Superseded
Headers show
Series xfs: small fixes for 5.12 | expand

Commit Message

Darrick J. Wong March 2, 2021, 10:28 p.m. UTC 
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(+)

Comments

Christoph Hellwig March 3, 2021, 6:48 a.m. UTC | #1 
On Tue, Mar 02, 2021 at 02:28:34PM -0800, Darrick J. Wong wrote:
> 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.

This looks ok, but I'm a little worried about sprinkling these log
forces and AIL pushes around.  We have a similar one but split int
the regular unmount path, and I wonder if we just need to regularize
that.
Darrick J. Wong March 3, 2021, 7:02 p.m. UTC | #2 
On Wed, Mar 03, 2021 at 07:48:12AM +0100, Christoph Hellwig wrote:
> On Tue, Mar 02, 2021 at 02:28:34PM -0800, Darrick J. Wong wrote:
> > 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.
> 
> This looks ok, but I'm a little worried about sprinkling these log
> forces and AIL pushes around.  We have a similar one but split int
> the regular unmount path, and I wonder if we just need to regularize
> that.

Hmm, the unmount path splits the log force and the ail split while we
wait for free extents to get discarded.  Log replay can free extents, so
at the very least I think we need to do that here too.

--D
diff mbox series

Patch

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