On Fri, Oct 17, 2014 at 09:14:34AM +1100, Dave Chinner wrote: > That smells like a splice architecture bug. splice write puts the > pipe lock outside the inode locks, but splice read puts the pipes > locks *inside* the inode locks. > > The recent commit 8d02076 "(->splice_write() via ->write_iter()") > which went into 3.16 will be what is causing this. It replaced a > long standing splice lock inversion problem (XFS iolock vs i_mutex > http://oss.sgi.com/archives/xfs/2011-08/msg00122.html) by moving > to a ->write_iter call under the pipe_lock. > > Only XFS reports this issue because XFS is the only filesystem that > serialises splice reads against truncate, concurrent writes into the > same region, extent manipulation functions via fallocate() (e.g. > hole punch), etc. and it does so via the inode iolock that it takes > in shared (read) mode during xfs_file_splice_read(). Actually ocfs2 and nfs will have the same issue. -- 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
