From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 0/5] splice: locking changes and code refactoring Date: Mon, 13 Jan 2014 06:14:16 -0800 Message-ID: <20140113141416.GA30117@infradead.org> References: <20131212181459.994196463@bombadil.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com To: Al Viro , Jens Axboe , Mark Fasheh , Joel Becker Return-path: Received: from bombadil.infradead.org ([198.137.202.9]:51590 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750899AbaAMOO1 (ORCPT ); Mon, 13 Jan 2014 09:14:27 -0500 Content-Disposition: inline In-Reply-To: <20131212181459.994196463@bombadil.infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: ping? Would be nice to get this into 3.14 On Thu, Dec 12, 2013 at 10:14:59AM -0800, Christoph Hellwig wrote: > 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(-) > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ---end quoted text---