[PATCH 0/2] xfs: fix recovery corruption on s390 w/ nrext64

[Dave Chinner <david@fromorbit.com>]

Hi folks,

The following are two patches to fix the corruption bug that
Zorro recently recently reported on big endian platforms when
nrext64 is enabled.

It is caused by recovery zeroing a v2 inode field even on v3 inodes.
Before nrext64, this wasn't an issue because the field in v3 inodes
was just padding (i.e. zeroes) and so writing zero to part of it was
never noticed. However, nrext64 uses this field for the 64 bit data
fork extent count, so zeroing part of it becomes a problem.

The zeroing is done to the xfs_log_dinode, which is held in host
format. Because of the layout of this field, on little endian
machines the di_flush_iter field overlaps the high 16 bits of
di_big_nextents, and so we didn't notice that recovery was
overwriting the the high bits of the extent count because it's
always going to be zero bytes (needs to go over 2^48 extents before
we'd notice) in testing contexts.

However, on big endian machines, the di_flushiter field overlays the
lower 16 bits of the di_big_extents field, and so zeroing
di_flushiter essentially rounds it down to the nearest 64k. For
typical testing contexts, that's effectively zeroing the extent
count.

The fix is two parts. The first patch adds detection of this
specific corruption to the xfs_dinode verifier, and adds a call to
the verifier after recovery has recovered the inode. This catches
corruptions at recovery time, rather than silently writing them back
and not noticing them until the inode is re-read from disk at
runtime.

The second patch fixes the recovery bug. It simply moves the
resetting of the di_flushiter field into the v2 inode specific
flushiter handling branch. That's always been wrong (i.e. since v3
inodes were introduced) but it hasn't mattered until now, so it
marked as fixing the introduction of the nrext64 feature....

-Dave.