On Mon, Jan 13, 2014 at 11:56:46PM +0000, Al Viro wrote: > On Mon, Jan 13, 2014 at 06:14:16AM -0800, Christoph Hellwig wrote: > > ping? Would be nice to get this into 3.14 > > Umm... The reason for pipe_lock outside of ->i_mutex is this: > default_file_splice_write() calls splice_from_pipe() with > write_pipe_buf for callback. splice_from_pipe() calls that > callback under pipe_lock(pipe). And write_pipe_buf() calls > __kernel_write(), which certainly might want to take ->i_mutex. > > Now, this codepath isn't taken for files that have non-NULL > ->splice_write(), so that's not an issue for XFS and OCFS2, > but having pipe_lock nest between the ->i_mutex for filesystems > that do and do not have ->splice_write()... Ouch... What would be the alternative? Duplicating the code in even more filesystems to enforce an non-natural locking order for filesystems actually implementing splice? There don't actually seem to be a whole lot of real filesystems not implemting splice_write, the prime use would be for device drivers or synthetic ones. I'm not even sure how much that fallback gets used in practice. -- 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
