From: Chandan Babu R <chandanbabu@kernel.org>
To: linux-xfs@vger.kernel.org
Cc: Chandan Babu R <chandanbabu@kernel.org>
Subject: [RFC PATCH] xfs: Prevent umount from indefinitely waiting on XFS_IFLUSHING flag on stale inodes
Date: Mon, 2 Sep 2024 13:20:41 +0530 [thread overview]
Message-ID: <20240902075045.1037365-1-chandanbabu@kernel.org> (raw)
Executing xfs/057 can lead to an unmount task to wait indefinitely for
XFS_IFLUSHING flag on some inodes to be cleared. The following timeline
describes as to how inodes can get into such a state.
Task A Task B Iclog endio processing
----------------------------------------------------------------------------
Inodes are freed
Inodes items are
added to the CIL
CIL contents are
written to iclog
iclog->ic_fail_crc
is set to true
iclog is submitted
for writing to the
disk
Last inode in the cluster
buffer is freed
XFS_[ISTALE/IFLUSHING] is
set on all inodes in the
cluster buffer
XFS_STALE is set on
the cluster buffer
iclog crc error is detected
... during endio processing
During xfs_trans_commit, Set XFS_LI_ABORTED on inode
log shutdown is detected items
XFS_LI_ABORTED is set xfs_inode_item_committed()
on xfs_buf_log_item - Unpin the inode since it
is stale and return -1
xfs_buf_log_item is freed
Inode log items are not
xfs_buf is not freed here processed further since
since b_hold has a xfs_inode_item_committed()
non-zero value returns -1
During normal operation, the stale inodes are processed by
xfs_buf_item_unpin() => xfs_buf_inode_iodone(). This ends up calling
xfs_iflush_abort() which in turn clears the XFS_IFLUSHING flag. However, in
the case of this bug, the xfs_buf_log_item is freed just before the high level
transaction is committed to the CIL.
To overcome this bug, this commit removes the check for log shutdown during
high level transaction commit operation. The log items in the high level
transaction will now be committed to the CIL despite the log being
shutdown. This will allow the CIL processing logic (i.e. xlog_cil_push_work())
to invoke xlog_cil_committed() as part of error handling. This will cause
xfs_buf log item to to be unpinned and the corresponding inodes to be aborted
and have their XFS_IFLUSHING flag cleared.
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
---
PS: I have tested this patch by executing xfs/057 in a loop for about 24 hours.
On a non-patched kernel, this issue gets recreated within 24 hours.
fs/xfs/xfs_trans.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c
index bdf3704dc301..b43436c8abaa 100644
--- a/fs/xfs/xfs_trans.c
+++ b/fs/xfs/xfs_trans.c
@@ -868,17 +868,6 @@ __xfs_trans_commit(
if (!(tp->t_flags & XFS_TRANS_DIRTY))
goto out_unreserve;
- /*
- * We must check against log shutdown here because we cannot abort log
- * items and leave them dirty, inconsistent and unpinned in memory while
- * the log is active. This leaves them open to being written back to
- * disk, and that will lead to on-disk corruption.
- */
- if (xlog_is_shutdown(log)) {
- error = -EIO;
- goto out_unreserve;
- }
-
ASSERT(tp->t_ticket != NULL);
/*
--
2.43.0
next reply other threads:[~2024-09-02 7:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-02 7:50 Chandan Babu R [this message]
2024-09-02 13:24 ` [RFC PATCH] xfs: Prevent umount from indefinitely waiting on XFS_IFLUSHING flag on stale inodes Dave Chinner
2024-09-05 12:42 ` Chandan Babu R
2024-09-16 5:44 ` Chandan Babu R
2024-09-18 1:20 ` Dave Chinner
2024-09-22 13:23 ` Chandan Babu R
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=20240902075045.1037365-1-chandanbabu@kernel.org \
--to=chandanbabu@kernel.org \
--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