[PATCH 0/5] splice: locking changes and code refactoring

[Christoph Hellwig]

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.