mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-16 01:04:08 +08:00
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>
This commit is contained in:
parent
4ab9ed578e
commit
72ab70a19b
@ -1609,12 +1609,21 @@ xfs_vm_write_begin(
|
||||
status = __block_write_begin(page, pos, len, xfs_get_blocks);
|
||||
if (unlikely(status)) {
|
||||
struct inode *inode = mapping->host;
|
||||
size_t isize = i_size_read(inode);
|
||||
|
||||
xfs_vm_write_failed(inode, page, pos, len);
|
||||
unlock_page(page);
|
||||
|
||||
if (pos + len > i_size_read(inode))
|
||||
truncate_pagecache(inode, i_size_read(inode));
|
||||
/*
|
||||
* If the write is beyond EOF, we only want to kill blocks
|
||||
* allocated in this write, not blocks that were previously
|
||||
* written successfully.
|
||||
*/
|
||||
if (pos + len > isize) {
|
||||
ssize_t start = max_t(ssize_t, pos, isize);
|
||||
|
||||
truncate_pagecache_range(inode, start, pos + len);
|
||||
}
|
||||
|
||||
page_cache_release(page);
|
||||
page = NULL;
|
||||
|
Loading…
Reference in New Issue
Block a user