diff options
author | Matthew Bobrowski <mbobrowski@mbobrowski.org> | 2019-11-05 23:02:23 +1100 |
---|---|---|
committer | Theodore Ts'o <tytso@mit.edu> | 2019-11-05 11:31:40 -0500 |
commit | 3eaf9cc62f447a742b26fa601993e94406aa1ea1 (patch) | |
tree | 5256bb4a4e7e8dc9af54b790a11e90927b50f5fe /fs/efs/super.c | |
parent | 0b9f230b94dd7457802264dc4c16921b3527dcf1 (diff) | |
download | linux-3eaf9cc62f447a742b26fa601993e94406aa1ea1.tar.bz2 |
ext4: update ext4_sync_file() to not use __generic_file_fsync()
When the filesystem is created without a journal, we eventually call
into __generic_file_fsync() in order to write out all the modified
in-core data to the permanent storage device. This function happens to
try and obtain an inode_lock() while synchronizing the files buffer
and it's associated metadata.
Generally, this is fine, however it becomes a problem when there is
higher level code that has already obtained an inode_lock() as this
leads to a recursive lock situation. This case is especially true when
porting across direct I/O to iomap infrastructure as we obtain an
inode_lock() early on in the I/O within ext4_dio_write_iter() and hold
it until the I/O has been completed. Consequently, to not run into
this specific issue, we move away from calling into
__generic_file_fsync() and perform the necessary synchronization tasks
within ext4_sync_file().
Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/3495f35ef67f2021b567e28e6f59222e583689b8.1572949325.git.mbobrowski@mbobrowski.org
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'fs/efs/super.c')
0 files changed, 0 insertions, 0 deletions