https://bugzilla.kernel.org/show_bug.cgi?id=43260 Eric Sandeen <sandeen@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sandeen@xxxxxxxxxx --- Comment #1 from Eric Sandeen <sandeen@xxxxxxxxxx> 2012-05-18 02:06:41 --- commit details: commit 8c0bec2151a47906bf779c6715a10ce04453ab77 Author: Jiaying Zhang <jiayingz@xxxxxxxxxx> Date: Wed Aug 31 11:50:51 2011 -0400 ext4: remove i_mutex lock in ext4_evict_inode to fix lockdep complaining The i_mutex lock and flush_completed_IO() added by commit 2581fdc810 in ext4_evict_inode() causes lockdep complaining about potential deadlock in several places. In most/all of these LOCKDEP complaints it looks like it's a false positive, since many of the potential circular locking cases can't take place by the time the ext4_evict_inode() is called; but since at the very least it may mask real problems, we need to address this. This change removes the flush_completed_IO() and i_mutex lock in ext4_evict_inode(). Instead, we take a different approach to resolve the software lockup that commit 2581fdc810 intends to fix. Rather than having ext4-dio-unwritten thread wait for grabing the i_mutex lock of an inode, we use mutex_trylock() instead, and simply requeue the work item if we fail to grab the inode's i_mutex lock. This should speed up work queue processing in general and also prevents the following deadlock scenario: During page fault, shrink_icache_memory is called that in turn evicts another inode B. Inode B has some pending io_end work so it calls ext4_ioend_wait() that waits for inode B's i_ioend_count to become zero. However, inode B's ioend work was queued behind some of inode A's ioend work on the same cpu's ext4-dio-unwritten workqueue. As the ext4-dio-unwritten thread on that cpu is processing inode A's ioend work, it tries to grab inode A's i_mutex lock. Since the i_mutex lock of inode A is still hold before the page fault happened, we enter a deadlock. Signed-off-by: Jiaying Zhang <jiayingz@xxxxxxxxxx> Signed-off-by: "Theodore Ts'o" <tytso@xxxxxxx> I tested on the 3.2.10 fedora kernel, though, and it didn't lock up (tried many times): # rm -f lockfile; ./ftruncate-test lockfile This might lock up.. It didn't lock up. Can you lock it up, and do a sysrq-w and maybe sysrq-d and attach the resulting dmesg? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- 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
