diff options
author | Carlos Maiolino <cmaiolino@redhat.com> | 2018-04-10 22:39:04 -0700 |
---|---|---|
committer | Darrick J. Wong <darrick.wong@oracle.com> | 2018-04-10 22:39:04 -0700 |
commit | 8c81dd46ef3c416b3b95e3020fb90dbd44e6140b (patch) | |
tree | 8d59cddfbe853660ef6f492356f9bfafcd74e078 /fs/jffs2/xattr.h | |
parent | fbbb4509048cf4e41a1254978859b588e0c86eab (diff) | |
download | op-kernel-dev-8c81dd46ef3c416b3b95e3020fb90dbd44e6140b.zip op-kernel-dev-8c81dd46ef3c416b3b95e3020fb90dbd44e6140b.tar.gz |
Force log to disk before reading the AGF during a fstrim
Forcing the log to disk after reading the agf is wrong, we might be
calling xfs_log_force with XFS_LOG_SYNC with a metadata lock held.
This can cause a deadlock when racing a fstrim with a filesystem
shutdown.
The deadlock has been identified due a miscalculation bug in device-mapper
dm-thin, which returns lack of space to its users earlier than the device itself
really runs out of space, changing the device-mapper volume into an error state.
The problem happened while filling the filesystem with a single file,
triggering the bug in device-mapper, consequently causing an IO error
and shutting down the filesystem.
If such file is removed, and fstrim executed before the XFS finishes the
shut down process, the fstrim process will end up holding the buffer
lock, and going to sleep on the cil wait queue.
At this point, the shut down process will try to wake up all the threads
waiting on the cil wait queue, but for this, it will try to hold the
same buffer log already held my the fstrim, locking up the filesystem.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Diffstat (limited to 'fs/jffs2/xattr.h')
0 files changed, 0 insertions, 0 deletions