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
