xfs
[Top] [All Lists]

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

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 0/5] splice: locking changes and code refactoring
From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Date: Mon, 13 Jan 2014 23:56:46 +0000
Cc: Jens Axboe <axboe@xxxxxxxxx>, Mark Fasheh <mfasheh@xxxxxxxx>, Joel Becker <jlbec@xxxxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140113141416.GA30117@xxxxxxxxxxxxx>
References: <20131212181459.994196463@xxxxxxxxxxxxxxxxxxxxxx> <20140113141416.GA30117@xxxxxxxxxxxxx>
Sender: Al Viro <viro@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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...

<Prev in Thread] Current Thread [Next in Thread>