mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-04 18:09:57 +00:00
udf: Fix file corruption when appending just after end of preallocated extent
commit36ec52ea03
upstream. When we append new block just after the end of preallocated extent, the code in inode_getblk() wrongly determined we're going to use the preallocated extent which resulted in adding block into a wrong logical offset in the file. Sequence like this manifests it: xfs_io -f -c "pwrite 0x2cacf 0xd122" -c "truncate 0x2dd6f" \ -c "pwrite 0x27fd9 0x69a9" -c "pwrite 0x32981 0x7244" <file> The code that determined the use of preallocated extent is actually stale because udf_do_extend_file() does not create preallocation anymore so after calling that function we are sure there's no usable preallocation. Just remove the faulty condition. CC: stable@vger.kernel.org Fixes:16d0556568
("udf: Discard preallocation before extending file with a hole") Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
parent
d747b31e29
commit
38a1f5e9fc
1 changed files with 11 additions and 13 deletions
|
@ -807,11 +807,10 @@ static sector_t inode_getblk(struct inode *inode, sector_t block,
|
|||
c = 0;
|
||||
offset = 0;
|
||||
count += ret;
|
||||
/* We are not covered by a preallocated extent? */
|
||||
if ((laarr[0].extLength & UDF_EXTENT_FLAG_MASK) !=
|
||||
EXT_NOT_RECORDED_ALLOCATED) {
|
||||
/* Is there any real extent? - otherwise we overwrite
|
||||
* the fake one... */
|
||||
/*
|
||||
* Is there any real extent? - otherwise we overwrite the fake
|
||||
* one...
|
||||
*/
|
||||
if (count)
|
||||
c = !c;
|
||||
laarr[c].extLength = EXT_NOT_RECORDED_NOT_ALLOCATED |
|
||||
|
@ -819,7 +818,6 @@ static sector_t inode_getblk(struct inode *inode, sector_t block,
|
|||
memset(&laarr[c].extLocation, 0x00,
|
||||
sizeof(struct kernel_lb_addr));
|
||||
count++;
|
||||
}
|
||||
endnum = c + 1;
|
||||
lastblock = 1;
|
||||
} else {
|
||||
|
|
Loading…
Reference in a new issue