On Fri, 14 Aug 2009 14:26:10 +0200 Jan Kara <jack@xxxxxxx> wrote: > 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 truncate_mutex and that violates > lock ordering because truncate_mutex ranks below transaction start (and it > can lead to a real deadlock with ext3_get_blocks() allocating new blocks > from ext3_writepage()). > > Luckily, the problem is easy to fix: We just drop the truncate_mutex before > restarting the transaction and acquire it afterwards. We are safe to do this as > by the time ext3_truncate() is called, all the page cache for the truncated > part of the file is dropped and so writepage() cannot come and allocate new > blocks in the part of the file we are truncating. The rest of writers is > stopped by us holding i_mutex. For ext2 we have the comment: /* * truncate_mutex is for serialising ext2_truncate() against * ext2_getblock(). It also protects the internals of the inode's * reservation data structures: ext2_reserve_window and * ext2_reserve_window_node. */ does truncate_mutex also protect ext3's reservation data? If so, is that impacted by this patch? -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
