On Tue, Mar 19, 2013 at 09:38:31PM +0000, Al Viro wrote: > On Tue, Mar 19, 2013 at 09:25:43PM +0100, Jan Kara wrote: > > > 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... > > Generally, the freeze protection should be the outermost lock taken (so > > that we mitigate possibility of blocking readers when waiting for fs to > > unfreeze). So it ranks above i_mutex, or XFS' ilock and iolock. > > Welcome to deadlock, then: > xfs_file_splice_write() > ... > xfs_ilock(ip, XFS_IOLOCK_EXCL); > ... > ret = generic_file_splice_write(pipe, outfilp, ppos, count, flags); > > > It seems that I screwed this up for ->splice_write() :-| If we are going to > > move out sb_start_write() out of filesystems' hands into do_splice_from() > > then we should likely do the same with ->aio_write(). Hmm? ... and then there's ext4_file_dio_write(), which cheerfully ignores freeze. ... and udf expanding from inline files to separately allocated before it gets to sb_start_write() ... and a bunch of guys doing generic_write_sync() after generic_aio_file_write() ... and a lot of other fun stuff. Ouch... OK, it's going to be an interesting series - aforementioned tentative patch was badly incomplete ;-/ -- 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
