This is a note to let you know that I've just added the patch titled xfs: force the log offline when log intent item recovery fails to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: xfs-force-the-log-offline-when-log-intent-item-recovery-fails.patch and it can be found in the queue-5.10 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable@xxxxxxxxxxxxxxx> know about it. >From foo@baz Mon Aug 1 10:39:45 AM CEST 2022 From: Amir Goldstein <amir73il@xxxxxxxxx> Date: Fri, 29 Jul 2022 18:16:05 +0200 Subject: xfs: force the log offline when log intent item recovery fails To: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> Cc: Sasha Levin <sashal@xxxxxxxxxx>, "Darrick J . Wong" <djwong@xxxxxxxxxx>, Leah Rumancik <leah.rumancik@xxxxxxxxx>, Chandan Babu R <chandan.babu@xxxxxxxxxx>, Luis Chamberlain <mcgrof@xxxxxxxxxx>, Adam Manzanares <a.manzanares@xxxxxxxxxxx>, linux-xfs@xxxxxxxxxxxxxxx, stable@xxxxxxxxxxxxxxx, Christoph Hellwig <hch@xxxxxx> Message-ID: <20220729161609.4071252-6-amir73il@xxxxxxxxx> From: "Darrick J. Wong" <djwong@xxxxxxxxxx> commit 4e6b8270c820c8c57a73f869799a0af2b56eff3e upstream. If any part of log intent item recovery fails, we should shut down the log immediately to stop the log from writing a clean unmount record to disk, because the metadata is not consistent. The inability to cancel a dirty transaction catches most of these cases, but there are a few things that have slipped through the cracks, such as ENOSPC from a transaction allocation, or runtime errors that result in cancellation of a non-dirty transaction. This solves some weird behaviors reported by customers where a system goes down, the first mount fails, the second succeeds, but then the fs goes down later because of inconsistent metadata. Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx> Reviewed-by: Christoph Hellwig <hch@xxxxxx> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> Acked-by: Darrick J. Wong <djwong@xxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- fs/xfs/xfs_log.c | 3 +++ fs/xfs/xfs_log_recover.c | 5 ++++- 2 files changed, 7 insertions(+), 1 deletion(-) --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -765,6 +765,9 @@ xfs_log_mount_finish( if (readonly) mp->m_flags |= XFS_MOUNT_RDONLY; + /* Make sure the log is dead if we're returning failure. */ + ASSERT(!error || (mp->m_log->l_flags & XLOG_IO_ERROR)); + return error; } --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -2457,8 +2457,10 @@ xlog_finish_defer_ops( error = xfs_trans_alloc(mp, &resv, dfc->dfc_blkres, dfc->dfc_rtxres, XFS_TRANS_RESERVE, &tp); - if (error) + if (error) { + xfs_force_shutdown(mp, SHUTDOWN_LOG_IO_ERROR); return error; + } /* * Transfer to this new transaction all the dfops we captured @@ -3454,6 +3456,7 @@ xlog_recover_finish( * this) before we get around to xfs_log_mount_cancel. */ xlog_recover_cancel_intents(log); + xfs_force_shutdown(log->l_mp, SHUTDOWN_LOG_IO_ERROR); xfs_alert(log->l_mp, "Failed to recover intents"); return error; } Patches currently in stable-queue which might be from amir73il@xxxxxxxxx are queue-5.10/xfs-hold-buffer-across-unpin-and-potential-shutdown-processing.patch queue-5.10/xfs-prevent-uaf-in-xfs_log_item_in_current_chkpt.patch queue-5.10/xfs-xfs_log_force_lsn-isn-t-passed-a-lsn.patch queue-5.10/xfs-logging-the-on-disk-inode-lsn-can-make-it-go-backwards.patch queue-5.10/xfs-enforce-attr3-buffer-recovery-order.patch queue-5.10/xfs-remove-dead-stale-buf-unpin-handling-code.patch queue-5.10/xfs-force-the-log-offline-when-log-intent-item-recovery-fails.patch queue-5.10/xfs-refactor-xfs_file_fsync.patch queue-5.10/xfs-fix-log-intent-recovery-enospc-shutdowns-when-inactivating-inodes.patch