From: Eric Sandeen <sandeen@sandeen.net>
To: Mark Tinguely <tinguely@sgi.com>
Cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>,
Eric Sandeen <sandeen@redhat.com>
Subject: Re: [PATCH V2] xfs: be more forgiving of a v4 secondary sb w/ junk in v5 fields
Date: Mon, 09 Sep 2013 16:10:22 -0500 [thread overview]
Message-ID: <522E393E.10902@sandeen.net> (raw)
In-Reply-To: <522E38DB.4020408@sgi.com>
On 9/9/13 4:08 PM, Mark Tinguely wrote:
> On 09/09/13 15:33, Eric Sandeen wrote:
>> 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.
>>
>> Stable folks: This can go back to v3.10, which is what
>> introduced the sb CRC checking that is tripped up by old,
>> stale, incorrect V4 superblocks w/ unzeroed bits.
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Eric Sandeen<sandeen@redhat.com>
>> ---
>>
>> V2: Comment changes: More! (No code changes)
>>
>> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
>> index 2b0ba35..b2deab1 100644
>> --- a/fs/xfs/xfs_mount.c
>> +++ b/fs/xfs/xfs_mount.c
>> @@ -749,6 +749,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(
>> @@ -769,8 +774,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);
>
> This moved to fs/xfs/xfs_sb.c in TOT, but the patch looks good to me.
Whoops, sorry. Thanks for the review. Want a resend?
(Any idea why your mail client eats spaces? "if (bp->b_bn != XFS_SB_DADDR&&" isn't
in the original patch...)
> Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Thanks,
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-09-09 21:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-15 18:19 [PATCH, RFC] xfs: don't verify checksum on non-V5 superblocks Eric Sandeen
2013-08-15 19:45 ` Ben Myers
2013-08-15 21:00 ` Dave Chinner
2013-08-15 21:15 ` Eric Sandeen
2013-08-15 22:41 ` [PATCH, RFC] xfs: be more forgiving of a v4 secondary sb w/ junk in v5 fields Eric Sandeen
2013-08-15 23:15 ` Dave Chinner
2013-09-09 20:33 ` [PATCH V2] " Eric Sandeen
2013-09-09 21:08 ` Mark Tinguely
2013-09-09 21:10 ` Eric Sandeen [this message]
2013-09-09 21:16 ` Mark Tinguely
2013-10-31 15:51 ` Ben Myers
2013-10-17 20:17 ` [PATCH, RFC] " Ben Myers
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=522E393E.10902@sandeen.net \
--to=sandeen@sandeen.net \
--cc=linux-xfs@oss.sgi.com \
--cc=sandeen@redhat.com \
--cc=tinguely@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.