From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Jones <davej@codemonkey.org.uk>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: iov_iter_pipe warning.
Date: Fri, 21 Apr 2017 18:54:30 +0100 [thread overview]
Message-ID: <20170421175430.GT29622@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20170412190318.srkkdytf2ebrjzrg@codemonkey.org.uk>
On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote:
> Well it's been running an hour without incident, which looks promising.
> I'll leave it run, but I'd say you're on the right track given how quick
> it reproduced so far.
Could you try this and see if it works? What happens is that unlike
e.g. generic_file_read_iter/generic_file_write_iter, NFS O_DIRECT handling
does not make sure that iov_iter had been advanced by the amount
actually transferred - it is left advanced by the amount *requested*.
mm/filemap.c code gets around that by taking a copy of iov_iter, feeding
it to ->direct_IO() and then advancing the original by the amount actually
done. That's what the previous patch had duplicated for NFS, but we have
a cleaner way to do that now - both for NFS and in mm/filemap.c. Namely,
use iov_iter_revert(). For NFS it means making nfs_direct_..._schedule_iovec()
return how much it has actually requested from server and having their
callers do iov_iter_revert() after nfs_direct_wait() has reported how much
has actually come through. I've similar patches for mm/filemap.c avoiding
the games with copy of iov_iter there, but those are not fixes per se,
so they are separate. This one just deals with NFS.
fix nfs O_DIRECT advancing iov_iter too much
It leaves the iterator advanced by the amount of IO it has requested
instead of the amount actually transferred. Among other things,
that confuses the hell out of generic_file_splice_read().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index aab32fc3d6a8..c1b5fed7c863 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -537,7 +537,7 @@ static ssize_t nfs_direct_read_schedule_iovec(struct nfs_direct_req *dreq,
if (put_dreq(dreq))
nfs_direct_complete(dreq);
- return 0;
+ return requested_bytes;
}
/**
@@ -566,7 +566,7 @@ ssize_t nfs_file_direct_read(struct kiocb *iocb, struct iov_iter *iter)
struct inode *inode = mapping->host;
struct nfs_direct_req *dreq;
struct nfs_lock_context *l_ctx;
- ssize_t result = -EINVAL;
+ ssize_t result = -EINVAL, requested;
size_t count = iov_iter_count(iter);
nfs_add_stats(mapping->host, NFSIOS_DIRECTREADBYTES, count);
@@ -600,14 +600,19 @@ ssize_t nfs_file_direct_read(struct kiocb *iocb, struct iov_iter *iter)
nfs_start_io_direct(inode);
NFS_I(inode)->read_io += count;
- result = nfs_direct_read_schedule_iovec(dreq, iter, iocb->ki_pos);
+ requested = nfs_direct_read_schedule_iovec(dreq, iter, iocb->ki_pos);
nfs_end_io_direct(inode);
- if (!result) {
+ if (requested > 0) {
result = nfs_direct_wait(dreq);
- if (result > 0)
+ if (result > 0) {
+ requested -= result;
iocb->ki_pos += result;
+ }
+ iov_iter_revert(iter, requested);
+ } else {
+ result = requested;
}
out_release:
@@ -954,7 +959,7 @@ static ssize_t nfs_direct_write_schedule_iovec(struct nfs_direct_req *dreq,
if (put_dreq(dreq))
nfs_direct_write_complete(dreq);
- return 0;
+ return requested_bytes;
}
/**
@@ -979,7 +984,7 @@ static ssize_t nfs_direct_write_schedule_iovec(struct nfs_direct_req *dreq,
*/
ssize_t nfs_file_direct_write(struct kiocb *iocb, struct iov_iter *iter)
{
- ssize_t result = -EINVAL;
+ ssize_t result = -EINVAL, requested;
size_t count;
struct file *file = iocb->ki_filp;
struct address_space *mapping = file->f_mapping;
@@ -1022,7 +1027,7 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct iov_iter *iter)
nfs_start_io_direct(inode);
- result = nfs_direct_write_schedule_iovec(dreq, iter, pos);
+ requested = nfs_direct_write_schedule_iovec(dreq, iter, pos);
if (mapping->nrpages) {
invalidate_inode_pages2_range(mapping,
@@ -1031,13 +1036,17 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct iov_iter *iter)
nfs_end_io_direct(inode);
- if (!result) {
+ if (requested > 0) {
result = nfs_direct_wait(dreq);
if (result > 0) {
+ requested -= result;
iocb->ki_pos = pos + result;
/* XXX: should check the generic_write_sync retval */
generic_write_sync(iocb, result);
}
+ iov_iter_revert(iter, requested);
+ } else {
+ result = requested;
}
out_release:
nfs_direct_req_release(dreq);
next prev parent reply other threads:[~2017-04-21 19:02 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-21 20:59 iov_iter_pipe warning Dave Jones
2017-04-05 22:02 ` Dave Jones
2017-04-10 19:28 ` Al Viro
2017-04-10 19:42 ` Dave Jones
2017-04-10 19:57 ` Al Viro
2017-04-10 23:48 ` Dave Jones
2017-04-11 0:22 ` Al Viro
2017-04-11 3:05 ` Dave Jones
2017-04-11 3:28 ` Al Viro
2017-04-11 20:53 ` Dave Jones
2017-04-11 21:12 ` Al Viro
2017-04-11 22:25 ` Dave Jones
2017-04-11 23:28 ` Al Viro
2017-04-11 23:34 ` Dave Jones
2017-04-11 23:48 ` Al Viro
2017-04-11 23:45 ` Dave Jones
2017-04-11 23:51 ` Al Viro
2017-04-11 23:56 ` Al Viro
2017-04-12 0:06 ` Dave Jones
2017-04-12 0:17 ` Al Viro
2017-04-12 0:58 ` Dave Jones
2017-04-12 1:15 ` Al Viro
2017-04-12 2:29 ` Dave Jones
2017-04-12 2:58 ` Al Viro
2017-04-12 14:35 ` Dave Jones
2017-04-12 15:26 ` Al Viro
2017-04-12 16:27 ` Dave Jones
2017-04-12 17:07 ` Al Viro
2017-04-12 19:03 ` Dave Jones
2017-04-21 17:54 ` Al Viro [this message]
2017-04-27 4:19 ` Dave Jones
2017-04-27 16:34 ` Dave Jones
2017-04-27 17:39 ` Al Viro
2017-04-28 15:29 ` Dave Jones
2017-04-28 16:43 ` Al Viro
2017-04-28 16:50 ` Dave Jones
2017-04-28 17:20 ` Al Viro
2017-04-28 18:25 ` Al Viro
2017-04-29 1:58 ` Dave Jones
2017-04-29 2:47 ` Al Viro
2017-04-29 15:51 ` Dave Jones
2017-04-29 20:46 ` [git pull] vfs.git fix (Re: iov_iter_pipe warning.) Al Viro
2017-08-07 20:18 ` iov_iter_pipe warning Dave Jones
2017-08-28 20:31 ` Dave Jones
2017-08-29 4:25 ` Darrick J. Wong
2017-08-30 17:05 ` Dave Jones
2017-08-30 17:13 ` Darrick J. Wong
2017-08-30 17:17 ` Dave Jones
2017-09-06 20:03 ` Dave Jones
2017-09-06 23:46 ` Dave Chinner
2017-09-07 3:48 ` Dave Jones
2017-09-07 4:33 ` Al Viro
2017-09-08 1:04 ` Al Viro
2017-09-10 1:07 ` Dave Jones
2017-09-10 2:57 ` Al Viro
2017-09-10 16:07 ` Dave Jones
2017-09-10 20:05 ` Al Viro
2017-09-10 20:07 ` Dave Jones
2017-09-10 20:33 ` Al Viro
2017-09-10 21:11 ` Dave Chinner
2017-09-10 21:19 ` Al Viro
2017-09-10 22:08 ` Dave Chinner
2017-09-10 23:07 ` Al Viro
2017-09-10 23:15 ` Al Viro
2017-09-11 0:31 ` Dave Chinner
2017-09-11 3:32 ` Al Viro
2017-09-11 6:44 ` Dave Chinner
2017-09-11 20:07 ` Al Viro
2017-09-11 20:17 ` Al Viro
2017-09-12 6:02 ` Dave Chinner
2017-09-12 11:13 ` Al Viro
2017-09-11 12:07 ` Christoph Hellwig
2017-09-11 12:51 ` Al Viro
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=20170421175430.GT29622@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=davej@codemonkey.org.uk \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox