From: Kevin Wolf <kwolf@redhat.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, afrosi@redhat.com, qemu-devel@nongnu.org,
mreitz@redhat.com
Subject: [RFC PATCH] curl: Allow reading after EOF
Date: Wed, 17 Mar 2021 16:17:34 +0100 [thread overview]
Message-ID: <20210317151734.41656-1-kwolf@redhat.com> (raw)
This makes the curl driver more consistent with file-posix in that it
doesn't return errors any more for reading after the end of the remote
file. Instead, zeros are returned for these areas.
This inconsistency was reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=1935061
Note that the image used in this bug report has a corrupted snapshot
table, which means that the qcow2 driver tries to do a zero-length read
after EOF on its image file.
The old behaviour of the curl driver can hardly be called a bug, but the
inconsistency turned out to be confusing.
Reported-by: Alice Frosi <afrosi@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
It is not entirely clear to me if this is something we want to do. If we
do care about consistency between protocol drivers, something like this
should probably be done in block/io.c eventually - but that would
require converting bs->total_sectors to byte granularity first.
Any opinions on what the most desirable semantics would be and whether
we should patch individual drivers until we can have a generic solution?
block/curl.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/block/curl.c b/block/curl.c
index 50e741a0d7..a8d87a1813 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -898,6 +898,7 @@ out:
static int coroutine_fn curl_co_preadv(BlockDriverState *bs,
uint64_t offset, uint64_t bytes, QEMUIOVector *qiov, int flags)
{
+ BDRVCURLState *s = bs->opaque;
CURLAIOCB acb = {
.co = qemu_coroutine_self(),
.ret = -EINPROGRESS,
@@ -906,6 +907,15 @@ static int coroutine_fn curl_co_preadv(BlockDriverState *bs,
.bytes = bytes
};
+ if (offset > s->len || bytes > s->len - offset) {
+ uint64_t req_bytes = offset > s->len ? 0 : s->len - offset;
+ qemu_iovec_memset(qiov, req_bytes, 0, bytes - req_bytes);
+ bytes = req_bytes;
+ }
+ if (bytes == 0) {
+ return 0;
+ }
+
curl_setup_preadv(bs, &acb);
while (acb.ret == -EINPROGRESS) {
qemu_coroutine_yield();
--
2.30.2
next reply other threads:[~2021-03-17 15:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 15:17 Kevin Wolf [this message]
2021-03-17 15:32 ` [RFC PATCH] curl: Allow reading after EOF Eric Blake
2021-03-17 15:46 ` Eric Blake
2021-03-17 16:38 ` Kevin Wolf
2021-03-17 16:12 ` Daniel P. Berrangé
2021-03-17 16:43 ` Kevin Wolf
2021-03-17 17:29 ` Eric Blake
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=20210317151734.41656-1-kwolf@redhat.com \
--to=kwolf@redhat.com \
--cc=afrosi@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).