diff options
author | Jin Xu <jinuxstyle@gmail.com> | 2013-08-05 20:02:04 +0800 |
---|---|---|
committer | Jaegeuk Kim <jaegeuk.kim@samsung.com> | 2013-08-06 22:00:36 +0900 |
commit | a569469e967022d9ceeaa4b73619f96614087d2d (patch) | |
tree | 530ddfa1940ce086cbc7e3711ea01a7c7f783786 /fs/nls | |
parent | df273efc36024a9ea97fd687d638a70c3ea8c37a (diff) | |
download | op-kernel-dev-a569469e967022d9ceeaa4b73619f96614087d2d.zip op-kernel-dev-a569469e967022d9ceeaa4b73619f96614087d2d.tar.gz |
f2fs: fix a deadlock in fsync
This patch fixes a deadlock bug that occurs quite often when there are
concurrent write and fsync on a same file.
Following is the simplified call trace when tasks get hung.
fsync thread:
- f2fs_sync_file
...
- f2fs_write_data_pages
...
- update_extent_cache
...
- update_inode
- wait_on_page_writeback
bdi writeback thread
- __writeback_single_inode
- f2fs_write_data_pages
- mutex_lock(sbi->writepages)
The deadlock happens when the fsync thread waits on a inode page that has
been added to the f2fs' cached bio sbi->bio[NODE], and unfortunately,
no one else could be able to submit the cached bio to block layer for
writeback. This is because the fsync thread already hold a sbi->fs_lock and
the sbi->writepages lock, causing the bdi thread being blocked when attempt
to write data pages for the same inode. At the same time, f2fs_gc thread
does not notice the situation and could not help. Even the sync syscall
gets blocked.
To fix it, we could submit the cached bio first before waiting on a inode page
that is being written back.
Signed-off-by: Jin Xu <jinuxstyle@gmail.com>
[Jaegeuk Kim: add more cases to use f2fs_wait_on_page_writeback]
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Diffstat (limited to 'fs/nls')
0 files changed, 0 insertions, 0 deletions