| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: Files with non-ASCII names inaccessible after xfs_repair, Zachary Kotlarek |
|---|---|
| Next by Date: | Re: Files with non-ASCII names inaccessible after xfs_repair, Dave Chinner |
| Previous by Thread: | Re: [PATCH 0/5] splice: locking changes and code refactoring, Christoph Hellwig |
| Next by Thread: | Re: [PATCH 0/5] splice: locking changes and code refactoring, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |