]> git.karo-electronics.de Git - karo-tx-linux.git/commit
ext4: Fix possible deadlock between ext4_truncate() and ext4_get_blocks()
authorJan Kara <jack@suse.cz>
Tue, 18 Aug 2009 02:17:20 +0000 (22:17 -0400)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 14 Dec 2009 16:06:12 +0000 (08:06 -0800)
commite2177295902d4849d61ad677e51e2d84eae617e5
tree663c6c1d43b6c0dffbe8c1e68d9cc2d50ebf73de
parent18623c3d1d26a30943cc1a97a99f385884f1ddca
ext4: Fix possible deadlock between ext4_truncate() and ext4_get_blocks()

During truncate we are sometimes forced to start a new transaction as
the amount of blocks to be journaled is both quite large and hard to
predict. So far we restarted a transaction while holding i_data_sem
and that violates lock ordering because i_data_sem ranks below a
transaction start (and it can lead to a real deadlock with
ext4_get_blocks() mapping blocks in some page while having a
transaction open).

(cherry picked from commit 487caeef9fc08c0565e082c40a8aaf58dad92bbb)

We fix the problem by dropping the i_data_sem before restarting the
transaction and acquire it afterwards. It's slightly subtle that this
works:

1) By the time ext4_truncate() is called, all the page cache for the
truncated part of the file is dropped so get_block() should not be
called on it (we only have to invalidate extent cache after we
reacquire i_data_sem because some extent from not-truncated part could
extend also into the part we are going to truncate).

2) Writes, migrate or defrag hold i_mutex so they are stopped for all
the time of the truncate.

This bug has been found and analyzed by Theodore Tso <tytso@mit.edu>.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fs/ext4/ext4.h
fs/ext4/extents.c
fs/ext4/inode.c