xfs
[Top] [All Lists]

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

To: Al Viro <viro@xxxxxxxxxxxxxxxxxx>, Jens Axboe <axboe@xxxxxxxxx>, Mark Fasheh <mfasheh@xxxxxxxx>, Joel Becker <jlbec@xxxxxxxxxxxx>
Subject: [PATCH 0/5] splice: locking changes and code refactoring
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 12 Dec 2013 10:14:59 -0800
Cc: linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
User-agent: quilt/0.60-1
I've been trying to fix the old splice iolock lock inversion issue in XFS
and started looking over the splice code a little more for it.  It seems
like the root of all evil is that we try to nest i_mutex inside the
pipe_lock instead of outside of it, and I can't find any good reason for
that.  Does anyone remember why it went this way initially?

By fixing that and a few minor issues we can not only fix this issue nicely
in XFS, but also get rid of various bits of code duplication, and poking into
splice internals by the ocfs2 splice_write path.

Btw, does anyone have a good test suite for splice functionality?  xfstests
coverage exits but is not very extensive.

 b/fs/ocfs2/file.c        |    2 
 b/fs/splice.c            |    5 +-
 b/fs/xfs/xfs_file.c      |   26 +++++-----
 b/include/linux/splice.h |    2 
 fs/ocfs2/file.c          |   78 +++++++++----------------------
 fs/splice.c              |  115 +++++++++++++----------------------------------
 include/linux/splice.h   |    7 --
 7 files changed, 76 insertions(+), 159 deletions(-)

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