xfs: write failure beyond EOF truncates too much data
authorDave Chinner <dchinner@redhat.com>
Mon, 14 Apr 2014 08:13:29 +0000 (18:13 +1000)
committerDave Chinner <david@fromorbit.com>
Mon, 14 Apr 2014 08:13:29 +0000 (18:13 +1000)
commit72ab70a19b4ebb19dbe2a79faaa6a4ccead58e70
treebcf20e96503e87d315a44904dd12f469721a5f26
parent4ab9ed578e82851645f3dd69d36d91ae77564d6c
xfs: write failure beyond EOF truncates too much data

If we fail a write beyond EOF and have to handle it in
xfs_vm_write_begin(), we truncate the inode back to the current inode
size. This doesn't take into account the fact that we may have
already made successful writes to the same page (in the case of block
size < page size) and hence we can truncate the page cache away from
blocks with valid data in them. If these blocks are delayed
allocation blocks, we now have a mismatch between the page cache and
the extent tree, and this will trigger - at minimum - a delayed
block count mismatch assert when the inode is evicted from the cache.
We can also trip over it when block mapping for direct IO - this is
the most common symptom seen from fsx and fsstress when run from
xfstests.

Fix it by only truncating away the exact range we are updating state
for in this write_begin call.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
fs/xfs/xfs_aops.c