summaryrefslogtreecommitdiffstats
path: root/fs/udf/file.c
diff options
context:
space:
mode:
authorMatthew Bobrowski <mbobrowski@mbobrowski.org>2019-11-05 22:59:37 +1100
committerTheodore Ts'o <tytso@mit.edu>2019-11-05 11:31:39 -0500
commit2e9b51d78229d5145725a481bb5464ebc0a3f9b2 (patch)
tree9c1bc23a708d04ba0e19223dfedbc750af9f1bc2 /fs/udf/file.c
parent548feebec7e93e58b647dba70b3303dcb569c914 (diff)
downloadlinux-2e9b51d78229d5145725a481bb5464ebc0a3f9b2.tar.bz2
ext4: iomap that extends beyond EOF should be marked dirty
This patch addresses what Dave Chinner had discovered and fixed within commit: 7684e2c4384d. This changes does not have any user visible impact for ext4 as none of the current users of ext4_iomap_begin() that extend files depend on IOMAP_F_DIRTY. When doing a direct IO that spans the current EOF, and there are written blocks beyond EOF that extend beyond the current write, the only metadata update that needs to be done is a file size extension. However, we don't mark such iomaps as IOMAP_F_DIRTY to indicate that there is IO completion metadata updates required, and hence we may fail to correctly sync file size extensions made in IO completion when O_DSYNC writes are being used and the hardware supports FUA. Hence when setting IOMAP_F_DIRTY, we need to also take into account whether the iomap spans the current EOF. If it does, then we need to mark it dirty so that IO completion will call generic_write_sync() to flush the inode size update to stable storage correctly. Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com> Link: https://lore.kernel.org/r/8b43ee9ee94bee5328da56ba0909b7d2229ef150.1572949325.git.mbobrowski@mbobrowski.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'fs/udf/file.c')
0 files changed, 0 insertions, 0 deletions