From: David Howells <dhowells@redhat.com>
To: Steve French <smfrench@gmail.com>
Cc: dhowells@redhat.com, "Paulo Alcantara" <pc@manguebit.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Long Li" <longli@microsoft.com>,
"Enzo Matsumiya" <ematsumiya@suse.de>,
"Shyam Prasad N" <nspmangalore@gmail.com>,
"Rohith Surabattula" <rohiths.msft@gmail.com>,
"Jeff Layton" <jlayton@kernel.org>,
linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] cifs: Fix unbuffered read
Date: Tue, 18 Apr 2023 23:40:07 +0100 [thread overview]
Message-ID: <1692048.1681857607@warthog.procyon.org.uk> (raw)
If read() is done in an unbuffered manner, such that, say,
cifs_strict_readv() goes through cifs_user_readv() and thence
__cifs_readv(), it doesn't recognise the EOF and keeps indicating to
userspace that it returning full buffers of data.
This is due to ctx->iter being advanced in cifs_send_async_read() as the
buffer is split up amongst a number of rdata objects. The iterator count
is then used in collect_uncached_read_data() in the non-DIO case to set the
total length read - and thus the return value of sys_read(). But since the
iterator normally gets used up completely during splitting, ctx->total_len
gets overridden to the full amount.
However, prior to that in collect_uncached_read_data(), we've gone through
the list of rdatas and added up the amount of data we actually received
(which we then throw away).
Fix this by removing the bit that overrides the amount read in the non-DIO
case and just going with the total added up in the aforementioned loop.
This was observed by mounting a cifs share with multiple channels, e.g.:
mount //192.168.6.1/test /test/ -o user=shares,pass=...,max_channels=6
and then reading a 1MiB file on the share:
strace cat /xfstest.test/1M >/dev/null
Through strace, the same data can be seen being read again and again.
Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list")
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Steve French <smfrench@gmail.com>
cc: Paulo Alcantara <pc@manguebit.com>
cc: Jérôme Glisse <jglisse@redhat.com>
cc: Long Li <longli@microsoft.com>
cc: Enzo Matsumiya <ematsumiya@suse.de>
cc: Shyam Prasad N <nspmangalore@gmail.com>
cc: Rohith Surabattula <rohiths.msft@gmail.com>
cc: Jeff Layton <jlayton@kernel.org>
cc: linux-cifs@vger.kernel.org
---
fs/cifs/file.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 321f9b7c84c9..f8877dc91cc5 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -4010,7 +4010,6 @@ static void
collect_uncached_read_data(struct cifs_aio_ctx *ctx)
{
struct cifs_readdata *rdata, *tmp;
- struct iov_iter *to = &ctx->iter;
struct cifs_sb_info *cifs_sb;
int rc;
@@ -4076,9 +4075,6 @@ collect_uncached_read_data(struct cifs_aio_ctx *ctx)
kref_put(&rdata->refcount, cifs_readdata_release);
}
- if (!ctx->direct_io)
- ctx->total_len = ctx->len - iov_iter_count(to);
-
/* mask nodata case */
if (rc == -ENODATA)
rc = 0;
next reply other threads:[~2023-04-18 22:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 22:40 David Howells [this message]
2023-04-19 2:16 ` Paulo Alcantara
2023-04-19 2:32 ` Steve French
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=1692048.1681857607@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=ematsumiya@suse.de \
--cc=jglisse@redhat.com \
--cc=jlayton@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=nspmangalore@gmail.com \
--cc=pc@manguebit.com \
--cc=rohiths.msft@gmail.com \
--cc=smfrench@gmail.com \
/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
all inboxes | Powered by JetHome®