From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: [RFC] mess in jbd2_block_tag_csum_verify() Date: Wed, 8 May 2013 16:51:30 +0100 Message-ID: <20130508155130.GT25399@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Theodore Ts'o , linux-fsdevel@vger.kernel.org To: "Darrick J. Wong" Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:58495 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756528Ab3EHPvf (ORCPT ); Wed, 8 May 2013 11:51:35 -0400 Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: You have calculated = jbd2_chksum(j, calculated, buf, j->j_blocksize); provided = be32_to_cpu(tag->t_checksum); return provided == cpu_to_be32(calculated); in there, which makes no sense whatsoever. First of all, you are converting big-endian to native, then another native to big-endian and compare results. The bogosity aside, it's equivalent to simply comparing tag->t_checksum with calculated - cpu_to_be32() is the same mapping as be32_to_cpu() on all architectures and it's a one-to-one mapping, at that. Bogosity, of course, is that tag->t_checksum is apparently big-endian and definitely a 16bit value. How in hell is that check going to yield true? Note that you are asking for 16 bits out of crc32c result to be zero, _NOT_ to be ignored. Producer of that value shoves lower 16 bits of cpu_to_be32(crc) into the on-disk structure. Also a bloody bad idea, since the values on little-endian and big-endian hosts will be different; move the disk from one box to another and watch the mismatches... What the hell is going on there?