summaryrefslogtreecommitdiff
path: root/fs/jbd2/commit.c
diff options
context:
space:
mode:
authorMatthew Bobrowski <mbobrowski@mbobrowski.org>2019-11-05 22:59:37 +1100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-01-04 19:17:13 +0100
commite48a6034482babeccdd6a2aac6f3b10beda35f26 (patch)
treeb3726ee9858ac57e36472b52e7f548891d8c3c5f /fs/jbd2/commit.c
parent339a860cdd0726477131c67e1d618844f2b64610 (diff)
ext4: iomap that extends beyond EOF should be marked dirty
[ Upstream commit 2e9b51d78229d5145725a481bb5464ebc0a3f9b2 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'fs/jbd2/commit.c')
0 files changed, 0 insertions, 0 deletions