From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: updated orangefs tree at kernel.org Date: Fri, 9 Oct 2015 00:03:33 +0100 Message-ID: <20151008230333.GX22011@ZenIV.linux.org.uk> References: <20151008210745.GW22011@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linus Torvalds , linux-fsdevel To: Mike Marshall Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:46085 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932580AbbJHXDg (ORCPT ); Thu, 8 Oct 2015 19:03:36 -0400 Content-Disposition: inline In-Reply-To: <20151008210745.GW22011@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Oct 08, 2015 at 10:07:45PM +0100, Al Viro wrote: > Am I missing anything subtle in there? Looks like do_readv_writev() would > get much simpler from that *and* ->read_iter()/->write_iter() will work > on arbitrary iov_iter after that... What I have in mind is something like (*ABSOLUTELY* *UNTESTED*) git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git orangefs-untested That's 8 commits on top of your #for-next: orangefs: explicitly pass the size to pvfs_bufmap_copy_to_iovec() pvfs_bufmap_copy_from_iovec(): don't rely upon size being equal to iov_iter_count(iter) orangefs: make postcopy_buffers() take iov_iter orangefs: make precopy_buffers() take iov_iter orangefs: make wait_for_direct_io() take iov_iter orangefs: don't bother with splitting iovecs orangefs: make do_readv_writev() take iov_iter orangefs: make pvfs2_inode_read() take iov_iter fs/orangefs/file.c | 344 +++++++------------------------------------------------------------------------------- fs/orangefs/inode.c | 17 ++--- fs/orangefs/pvfs2-bufmap.c | 52 ++++++------- fs/orangefs/pvfs2-bufmap.h | 3 +- fs/orangefs/pvfs2-kernel.h | 3 +- 5 files changed, 61 insertions(+), 358 deletions(-) Might take care of iov_iter-related issues (and get rid of arseloads of manual messing with iovecs, while we are at it). Again, this is really, really untested - might chew your data, etc. It compiles, but that's it. I easily might've missed something something subtle (or trivial, for that matter). And I haven't looked at the rest yet - some bugs I've mentioned are definitely still there (e.g. bogus iput() on failure of d_make_root() - it's already done by d_make_root() itself in that case, so what you are doing is double iput(); just remove it and be done with that), but I hadn't checked the whole list. Will post more later tonight...