Re: [PATCH, RFC] xfs: don't verify checksum on non-V5 superblocks

From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>,
	Eric Sandeen <sandeen@redhat.com>
Subject: Re: [PATCH, RFC] xfs: don't verify checksum on non-V5 superblocks
Date: Thu, 15 Aug 2013 16:15:19 -0500	[thread overview]
Message-ID: <520D44E7.1000905@sandeen.net> (raw)
In-Reply-To: <20130815210018.GR6023@dastard>

On 8/15/13 4:00 PM, Dave Chinner wrote:
> On Thu, Aug 15, 2013 at 01:19:15PM -0500, Eric Sandeen wrote:
>> The current test in xfs_sb_read_verify() will attempt to validate
>> an sb checksum if sb_crc is non-zero, even if the superblock is not
>> marked as being version 5.
>>
>> This runs the risk of picking up random garbage in sb_crc for non-V5
>> superblocks; such garbage is known to exist in the wild due to prior bugs.
>> This will cause verification to fail for otherwise non-fatal reasons.
>>
>> I'm not sure of the point of trying to validate a non-V5 superblock;
>> is there one?  Shouldn't this || be an &&?  (Can sb_crc validly be
>> 0 for a V5 SB?)
> 
> I don't think so.
> 
> As I mentioned on the call, the reason for this check is that if we
> have a CRC set and a non-v5 superblock version, we may have a
> corrupt superblock with bit errors in it. In this case, we check the
> CRC to determine if the superblock is intact. If the CRC validates,
> then it means that we wrote a bad superblock to disk (i.e. a code
> bug). If it doesn't validate, then the superblock is in a corrupt
> state because all fields not understood by the v4 superblock should
> be zero.
> 
> That's why if the checksum fails we are returning EFSCORRUPTED.
> 
> The problem we see here is not the validation of the primary
> superblock - it's the secondary superblocks that have been written
> by growfs that are the problem. We already know that we are
> verifying a secondary superblock by the "check_inprogress"
> parameter. Hence if we get this problem on a secondary superblock we
> can verify it against the primary superblock via the struct
> xfs_mount (i.e. mp->m_sb.sb_versionnum) and determine whether we do
> indeed have a v4 or v5 superblock and hence determine whether we
> should error out or just warn about it.

Ok, let me resend a patch under the same subject, different implementation :)

-Eric

> Cheers,
> 
> Dave.
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs