ext4: update ext4_sync_file() to not use __generic_file_fsync()
authorMatthew Bobrowski <mbobrowski@mbobrowski.org>
Tue, 5 Nov 2019 12:02:23 +0000 (23:02 +1100)
committerTheodore Ts'o <tytso@mit.edu>
Tue, 5 Nov 2019 16:31:40 +0000 (11:31 -0500)
commit3eaf9cc62f447a742b26fa601993e94406aa1ea1
tree5256bb4a4e7e8dc9af54b790a11e90927b50f5fe
parent0b9f230b94dd7457802264dc4c16921b3527dcf1
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>
fs/ext4/fsync.c