On Wed, Sep 27, 2023 at 07:23:37AM -0400, Brian Foster wrote: > An fsstress task on a big endian system (s390x) quickly produces a > bunch of CRC errors in the system logs. Most of these are related to > the narrow CRCs path, but the fundamental problem can be reduced to > a single write and re-read (after dropping caches) of a previously > merged extent. > > The key merge path that handles extent merges eventually calls into > bch2_checksum_merge() to combine the CRCs of the associated extents. > This code attempts to avoid a byte order swap by feeding the le64 > values into the crc32c code, but the latter casts the resulting u64 > value down to a u32, which truncates the high bytes where the actual > crc value ends up. This results in a CRC value that does not change > (since it is merged with a CRC of 0), and checksum failures ensue. > > Fix the checksum merge code to swap to cpu byte order on the > boundaries to the external crc code such that any value casting is > handled properly.
Thanks! Applied. We really need to test creating a filesystem and then reading from it on an opposite endianness machine, have you gotten a chance to do that? Otherwise, there's the big endian support in ktest to start looking at again.
