summaryrefslogtreecommitdiffstats
path: root/fs/dcache.c
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2013-05-28 18:37:17 +1000
committerBen Myers <bpm@sgi.com>2013-05-30 17:22:54 -0500
commite400d27d1690d609f203f2d7d8efebc98cbc3089 (patch)
tree6bb2cdbfb4e6d8ccb650d10e03683e291eeb6c10 /fs/dcache.c
parent7c9950fd2ac97431230544142d5e652e1b948372 (diff)
xfs: fix dir3 freespace block corruption
When the directory freespace index grows to a second block (2017 4k data blocks in the directory), the initialisation of the second new block header goes wrong. The write verifier fires a corruption error indicating that the block number in the header is zero. This was being tripped by xfs/110. The problem is that the initialisation of the new block is done just fine in xfs_dir3_free_get_buf(), but the caller then users a dirv2 structure to zero on-disk header fields that xfs_dir3_free_get_buf() has already zeroed. These lined up with the block number in the dir v3 header format. While looking at this, I noticed that the struct xfs_dir3_free_hdr() had 4 bytes of padding in it that wasn't defined as padding or being zeroed by the initialisation. Add a pad field declaration and fully zero the on disk and in-core headers in xfs_dir3_free_get_buf() so that this is never an issue in the future. Note that this doesn't change the on-disk layout, just makes the 32 bits of padding in the layout explicit. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Ben Myers <bpm@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com> (cherry picked from commit 5ae6e6a401957698f2bd8c9f4a86d86d02199fea)
Diffstat (limited to 'fs/dcache.c')
0 files changed, 0 insertions, 0 deletions