On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote: > IMO the deadlock is real. In freeze_super() we wait for all writers to > the filesystem to finish while blocking beginning of any further writes. So > we have a deadlock scenario like: > > THREAD1 THREAD2 THREAD3 > mnt_want_write() mutex_lock(&inode->i_mutex); > ... freeze_super() > block on mutex_lock(&inode->i_mutex) > sb_wait_write(sb, > SB_FREEZE_WRITE); > block in sb_start_write()
The bug is on fsfreeze side and this is not the only problem related to it. I've missed the implications when I applied "fs: Add freezing handling to mnt_want_write() / mnt_drop_write()" last June ;-/ The thing is, until then mnt_want_write() used to be a counter; it could be nested. Now any such nesting is a deadlock you've just described. This is seriously wrong, IMO. BTW, having sb_start_write() buried in individual ->splice_write() is asking for trouble; could you describe the rules for that? E.g. where does it nest wrt filesystem-private locks? XFS iolock, for example... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
