From: Theodore Ts'o Date: Fri, 26 Aug 2011 03:26:01 +0000 (-0400) Subject: ext4: fix potential deadlock in ext4_evict_inode() X-Git-Tag: next-20110830~75^2 X-Git-Url: https://git.karo-electronics.de/?a=commitdiff_plain;h=a840f388e87f75c18c51e1d868fdcd2ef23e9cea;p=karo-tx-linux.git ext4: fix potential deadlock in ext4_evict_inode() Commit 2581fdc810 moved ext4_ioend_wait() from ext4_destroy_inode() to ext4_evict_inode(). It also added code to explicitly call ext4_flush_completed_IO(inode): mutex_lock(&inode->i_mutex); ext4_flush_completed_IO(inode); mutex_unlock(&inode->i_mutex); Unfortunately, we can't take the i_mutex lock in ext4_evict_inode() without potentially causing a deadlock. Fix this by removing the code sequence altogether. This may result in ext4_evict_inode() taking longer to complete, but that's ok, we're not in a rush here. That just means we have to wait until the workqueue is scheduled, which is OK; there's nothing that says we have to do this work on the current thread, which would require taking a lock that might lead to a deadlock condition. See Kernel Bugzilla #41682 for one example of the circular locking problem that arise. Another one can be seen here: ======================================================= [ INFO: possible circular locking dependency detected ] 3.1.0-rc3-00012-g2a22fc1 #1839 ------------------------------------------------------- dd/7677 is trying to acquire lock: (&type->s_umount_key#18){++++..}, at: [] writeback_inodes_sb_if_idle+0x26/0x3d but task is already holding lock: (&sb->s_type->i_mutex_key#3){+.+.+.}, at: [] generic_file_aio_write+0x52/0xba which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&sb->s_type->i_mutex_key#3){+.+.+.}: [] lock_acquire+0x99/0xbd [] __mutex_lock_common+0x33/0x2fb [] mutex_lock_nested+0x26/0x2f [] ext4_evict_inode+0x3e/0x2bd [] evict+0x8e/0x131 [] dispose_list+0x36/0x40 [] evict_inodes+0xcd/0xd5 [] generic_shutdown_super+0x3d/0xaa [] kill_block_super+0x22/0x5e [] deactivate_locked_super+0x22/0x4e [] deactivate_super+0x3d/0x43 [] mntput_no_expire+0xda/0xdf [] sys_umount+0x286/0x2ab [] sys_oldumount+0x12/0x14 [] syscall_call+0x7/0xb -> #0 (&type->s_umount_key#18){++++..}: [] __lock_acquire+0x967/0xbd2 [] lock_acquire+0x99/0xbd [] down_read+0x28/0x65 [] writeback_inodes_sb_if_idle+0x26/0x3d [] ext4_nonda_switch+0xd0/0xe1 [] ext4_da_write_begin+0x3c/0x1cf [] generic_file_buffered_write+0xc0/0x1b4 [] __generic_file_aio_write+0x254/0x285 [] generic_file_aio_write+0x6a/0xba [] ext4_file_write+0x1d6/0x227 [] do_sync_write+0x8f/0xca [] vfs_write+0x85/0xe3 [] sys_write+0x40/0x65 [] syscall_call+0x7/0xb https://bugzilla.kernel.org/show_bug.cgi?id=41682 Cc: stable@kernel.org Cc: Jiaying Zhang Signed-off-by: "Theodore Ts'o" --- diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index b77f20b6ea6a..b84f127c085d 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -121,9 +121,6 @@ void ext4_evict_inode(struct inode *inode) trace_ext4_evict_inode(inode); - mutex_lock(&inode->i_mutex); - ext4_flush_completed_IO(inode); - mutex_unlock(&inode->i_mutex); ext4_ioend_wait(inode); if (inode->i_nlink) {