From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: [PATCH 01/13] libxfs: be more forgiving of a v4 secondary sb w/ junk in v5 fields
Date: Tue, 4 Mar 2014 19:51:45 +1100 [thread overview]
Message-ID: <1393923117-9559-2-git-send-email-david@fromorbit.com> (raw)
In-Reply-To: <1393923117-9559-1-git-send-email-david@fromorbit.com>
From: Dave Chinner <dchinner@redhat.com>
[userspace port]
Today, if xfs_sb_read_verify encounters a v4 superblock
with junk past v4 fields which includes data in sb_crc,
it will be treated as a failing checksum and a significant
corruption.
There are known prior bugs which leave junk at the end
of the V4 superblock; we don't need to actually fail the
verification in this case if other checks pan out ok.
So if this is a secondary superblock, and the primary
superblock doesn't indicate that this is a V5 filesystem,
don't treat this as an actual checksum failure.
We should probably check the garbage condition as
we do in xfs_repair, and possibly warn about it
or self-heal, but that's a different scope of work.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
libxfs/xfs_sb.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libxfs/xfs_sb.c b/libxfs/xfs_sb.c
index 48b1a97..16088a6 100644
--- a/libxfs/xfs_sb.c
+++ b/libxfs/xfs_sb.c
@@ -542,6 +542,11 @@ xfs_sb_verify(
* single bit error could clear the feature bit and unused parts of the
* superblock are supposed to be zero. Hence a non-null crc field indicates that
* we've potentially lost a feature bit and we should check it anyway.
+ *
+ * However, past bugs (i.e. in growfs) left non-zeroed regions beyond the
+ * last field in V4 secondary superblocks. So for secondary superblocks,
+ * we are more forgiving, and ignore CRC failures if the primary doesn't
+ * indicate that the fs version is V5.
*/
static void
xfs_sb_read_verify(
@@ -562,8 +567,12 @@ xfs_sb_read_verify(
if (!xfs_verify_cksum(bp->b_addr, be16_to_cpu(dsb->sb_sectsize),
offsetof(struct xfs_sb, sb_crc))) {
- error = EFSCORRUPTED;
- goto out_error;
+ /* Only fail bad secondaries on a known V5 filesystem */
+ if (bp->b_bn != XFS_SB_DADDR &&
+ xfs_sb_version_hascrc(&mp->m_sb)) {
+ error = EFSCORRUPTED;
+ goto out_error;
+ }
}
}
error = xfs_sb_verify(bp, true);
--
1.9.0
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-03-04 8:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 8:51 [PATCH 00/13] xfsprogs: initial EFSBADCRC support Dave Chinner
2014-03-04 8:51 ` Dave Chinner [this message]
2014-03-04 8:51 ` [PATCH 02/13] libxfs: sanitize sb_inopblock in xfs_mount_validate_sb Dave Chinner
2014-03-04 8:51 ` [PATCH 03/13] libxfs: xfs_sb_read_verify() doesn't flag bad crcs on primary sb Dave Chinner
2014-03-04 8:51 ` [PATCH 04/13] libxfs: skip verification on initial "guess" superblock read Dave Chinner
2014-03-04 8:51 ` [PATCH 05/13] libxfs: limit superblock corruption errors to actual corruption Dave Chinner
2014-03-04 8:51 ` [PATCH 06/13] libxfs: skip pointless CRC updates after verifier failures Dave Chinner
2014-03-04 8:51 ` [PATCH 07/13] libxfs: Use defines for CRC offsets in all cases Dave Chinner
2014-03-04 8:51 ` [PATCH 08/13] libxfs: add helper for verifying checksums on xfs_bufs Dave Chinner
2014-03-04 8:51 ` [PATCH 09/13] libxfs: add helper for updating " Dave Chinner
2014-03-04 8:51 ` [PATCH 10/13] libxfs: add xfs_verifier_error() Dave Chinner
2014-03-04 8:51 ` [PATCH 11/13] libxfs: modify verifiers to differentiate CRC from other errors Dave Chinner
2014-03-04 8:51 ` [PATCH 12/13] xfs_db: Use EFSBADCRC for CRC validity indication Dave Chinner
2014-03-05 0:12 ` Eric Sandeen
2014-03-04 8:51 ` [PATCH 13/13] repair: phase 1 does not handle superblock CRCs Dave Chinner
2014-03-06 16:01 ` Brian Foster
2014-03-06 23:22 ` Dave Chinner
2014-03-05 0:04 ` [PATCH 00/13] xfsprogs: initial EFSBADCRC support Eric Sandeen
2014-03-07 10:46 ` Christoph Hellwig
2014-03-07 22:50 ` Dave Chinner
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=1393923117-9559-2-git-send-email-david@fromorbit.com \
--to=david@fromorbit.com \
--cc=xfs@oss.sgi.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 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.