FYI, I just sent out a patch to the linux-ext4@ that uses mutex_trylock() in ext4_end_io_work() and removes the i_mutex lock and ext4_flush_completed_IO() in ext4_evict_inode(): http://www.spinics.net/lists/linux-ext4/msg27407.html Jiaying On Fri, Aug 26, 2011 at 10:17 PM, Jiaying Zhang <jiayingz@xxxxxxxxxx> wrote: > On Fri, Aug 26, 2011 at 1:22 PM, Ted Ts'o <tytso@xxxxxxx> wrote: >> On Fri, Aug 26, 2011 at 09:58:45AM -0700, Jiaying Zhang wrote: >>> Now thinking about an alternative approach to resolve the deadlock >>> mentioned above, maybe we can use mutex_trylock() in >>> ext4_end_io_work() and if we can't grab the mutex lock for an inode, >>> just requeue the work to the end of workqueue? >> >> Good idea! That should speed up work queue processing in general, I >> think. >> >> The downside is that inodes that currently locked might take longer to >> complete. In the case of fsync() we'll just force the I/O completion >> to happen in the context of the fsync'ing process, so I don't think it >> should be a problem in practice I think. >> > Ted, > > I am working on a patch to use mutex_trylock() in ext4_end_io_work() > so that we can fix the described deadlock without needing to call > mutex_lock() and ext4_flush_completed_IO() in ext4_evict_inode(). > I run into some problem while testing it. Given that the deadlock my > original patch intended to fix only exists with dioread_nolock enabled > but the lockdep issue happens in all of cases, I think we should roll > that part back as you have planned. I am going to send a separate patch > later to fix the deadlock issue once I resolved the problem found in > my test. > > Jiaying > >> - Ted >> > -- 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
