From: Al Viro <viro@ZenIV.linux.org.uk>
To: Mike Marshall <hubcap@omnibond.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: updated orangefs tree at kernel.org
Date: Fri, 9 Oct 2015 00:03:33 +0100 [thread overview]
Message-ID: <20151008230333.GX22011@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20151008210745.GW22011@ZenIV.linux.org.uk>
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...
next prev parent reply other threads:[~2015-10-08 23:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 20:07 updated orangefs tree at kernel.org Mike Marshall
2015-10-08 21:07 ` Al Viro
2015-10-08 23:03 ` Al Viro [this message]
2015-10-09 3:41 ` Al Viro
2015-10-09 6:13 ` Al Viro
2015-10-09 19:22 ` Al Viro
2015-10-10 2:31 ` Al Viro
2015-10-10 20:23 ` Al Viro
2015-10-10 23:10 ` orangefs: NAK until the ABI is documented (was Re: updated orangefs tree at kernel.org) Al Viro
2015-10-12 16:20 ` Mike Marshall
2015-10-12 19:16 ` Al Viro
2015-10-13 17:46 ` Mike Marshall
2015-10-13 23:34 ` Al Viro
-- strict thread matches above, loose matches on Subject: below --
2015-11-16 20:01 updated orangefs tree at kernel.org Mike Marshall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151008230333.GX22011@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=hubcap@omnibond.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.