On Tue, Feb 15, 2011 at 05:06:30PM +0100, Jan Kara wrote: > Thanks for detailed analysis. Indeed this is a bug. Whenever we do IO > under s_umount semaphore, we are prone to deadlock like the one you > describe above. One of the fundamental problems here is that the freeze and thaw routines are using down_write(&sb->s_umount) for two purposes. The first is to prevent the resume/thaw from racing with a umount (which it could do just as well by taking a read lock), but the second is to prevent the resume/thaw code from racing with itself. That's the core fundamental problem here. So I think we can solve this by introduce a new mutex, s_freeze, and having the the resume/thaw first take the s_freeze mutex and then second take a read lock on the s_umount. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
