From: Dave Chinner <david@fromorbit.com>
To: Zirong Lang <zlang@redhat.com>
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org,
"Darrick J. Wong" <djwong@kernel.org>,
Carlos Maiolino <carlos@maiolino.me>
Subject: Re: [Bug report][fstests generic/047] Internal error !(flags & XFS_DABUF_MAP_HOLE_OK) at line 2572 of file fs/xfs/libxfs/xfs_da_btree.c. Caller xfs_dabuf_map.constprop.0+0x26c/0x368 [xfs]
Date: Thu, 9 Nov 2023 17:14:51 +1100 [thread overview]
Message-ID: <ZUx429/S9H07xLrA@dread.disaster.area> (raw)
In-Reply-To: <CAN=2_H+CdEK_rEUmYbmkCjSRqhX2cwi5yRHQcKAmKDPF16vqOw@mail.gmail.com>
On Thu, Nov 09, 2023 at 10:43:58AM +0800, Zirong Lang wrote:
> By changing the generic/047 as below, I got 2 dump files and 2 log files.
> Please check the attachment,
> and feel free to tell me if you need more.
Well, we've narrowed down to some weird recovery issue - the journal
is intact, recovery recovers the inode from the correct log item in
the journal, but the inode written to disk by recovery is corrupt.
What this points out is that we don't actually verify the inode we
recover is valid before writeback is queued, nor do we detect the
specific corruption being encountered in the verifier (i.e. non-zero
nblocks count when extent count is zero).
Can you add the patch below and see if/when the verifier fires on
the reproducer? I'm particularly interested to know where it fires -
in recovery before writeback, or when the root inode is re-read from
disk. It doesn't fire on x64-64....
-Dave.
--
Dave Chinner
david@fromorbit.com
xfs: inode recovery does not validate the recovered inode
From: Dave Chinner <dchinner@redhat.com>
Discovered when trying to track down a weird recovery corruption
issue that wasn't detected at recovery time.
The specific corruption was a zero extent count field when big
extent counts are in use, and it turns out the dinode verifier
doesn't detect that specific corruption case, either. So fix it too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
fs/xfs/libxfs/xfs_inode_buf.c | 3 +++
fs/xfs/xfs_inode_item_recover.c | 14 +++++++++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/libxfs/xfs_inode_buf.c b/fs/xfs/libxfs/xfs_inode_buf.c
index a35781577cad..0f970a0b3382 100644
--- a/fs/xfs/libxfs/xfs_inode_buf.c
+++ b/fs/xfs/libxfs/xfs_inode_buf.c
@@ -508,6 +508,9 @@ xfs_dinode_verify(
if (mode && nextents + naextents > nblocks)
return __this_address;
+ if (nextents + naextents == 0 && nblocks != 0)
+ return __this_address;
+
if (S_ISDIR(mode) && nextents > mp->m_dir_geo->max_extents)
return __this_address;
diff --git a/fs/xfs/xfs_inode_item_recover.c b/fs/xfs/xfs_inode_item_recover.c
index 6b09e2bf2d74..f4c31c2b60d5 100644
--- a/fs/xfs/xfs_inode_item_recover.c
+++ b/fs/xfs/xfs_inode_item_recover.c
@@ -286,6 +286,7 @@ xlog_recover_inode_commit_pass2(
struct xfs_log_dinode *ldip;
uint isize;
int need_free = 0;
+ xfs_failaddr_t fa;
if (item->ri_buf[0].i_len == sizeof(struct xfs_inode_log_format)) {
in_f = item->ri_buf[0].i_addr;
@@ -529,8 +530,19 @@ xlog_recover_inode_commit_pass2(
(dip->di_mode != 0))
error = xfs_recover_inode_owner_change(mp, dip, in_f,
buffer_list);
- /* re-generate the checksum. */
+ /* re-generate the checksum and validate the recovered inode. */
xfs_dinode_calc_crc(log->l_mp, dip);
+ fa = xfs_dinode_verify(log->l_mp, in_f->ilf_ino, dip);
+ if (fa) {
+ XFS_CORRUPTION_ERROR(
+ "Bad dinode after recovery",
+ XFS_ERRLEVEL_LOW, mp, dip, sizeof(*dip));
+ xfs_alert(mp,
+ "Metadata corruption detected at %pS, inode 0x%llx",
+ fa, in_f->ilf_ino);
+ error = -EFSCORRUPTED;
+ goto out_release;
+ }
ASSERT(bp->b_mount == mp);
bp->b_flags |= _XBF_LOGRECOVERY;
next prev parent reply other threads:[~2023-11-09 6:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-29 4:11 [Bug report][fstests generic/047] Internal error !(flags & XFS_DABUF_MAP_HOLE_OK) at line 2572 of file fs/xfs/libxfs/xfs_da_btree.c. Caller xfs_dabuf_map.constprop.0+0x26c/0x368 [xfs] Zorro Lang
2023-11-06 6:13 ` Dave Chinner
2023-11-06 19:26 ` Zorro Lang
2023-11-06 20:33 ` Dave Chinner
2023-11-06 22:20 ` Darrick J. Wong
2023-11-07 8:05 ` Zorro Lang
2023-11-07 8:13 ` Dave Chinner
2023-11-07 15:13 ` Zorro Lang
2023-11-08 6:38 ` Dave Chinner
[not found] ` <CAN=2_H+CdEK_rEUmYbmkCjSRqhX2cwi5yRHQcKAmKDPF16vqOw@mail.gmail.com>
2023-11-09 6:14 ` Dave Chinner [this message]
2023-11-09 14:09 ` Zorro Lang
2023-11-09 23:13 ` Dave Chinner
2023-11-10 1:36 ` Zorro Lang
2023-11-10 2:03 ` Dave Chinner
2023-11-10 4:32 ` Darrick J. Wong
2023-11-10 7:34 ` Christoph Hellwig
2023-11-10 13:56 ` Zorro Lang
2023-11-14 11:17 ` edward6
2023-11-07 8:29 ` Christoph Hellwig
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=ZUx429/S9H07xLrA@dread.disaster.area \
--to=david@fromorbit.com \
--cc=carlos@maiolino.me \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@redhat.com \
/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