From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>,
qemu-block@nongnu.org, Jeff Cody <jcody@redhat.com>,
qemu-stable@nongnu.org, qemu-devel@nongnu.org, mbooth@redhat.com,
rjones@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/4] block/curl: Fix return value from curl_read_cb
Date: Wed, 26 Oct 2016 11:17:37 +0200 [thread overview]
Message-ID: <20161026091737.GH4758@noname.str.redhat.com> (raw)
In-Reply-To: <998633c9-ab39-0674-c25c-5c1b185b99e7@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]
Am 25.10.2016 um 20:37 hat Eric Blake geschrieben:
> On 10/24/2016 09:54 PM, Max Reitz wrote:
> > While commit 38bbc0a580f9f10570b1d1b5d3e92f0e6feb2970 is correct in that
> > the callback is supposed to return the number of bytes handled; what it
> > does not mention is that libcurl will throw an error if the callback did
> > not "handle" all of the data passed to it.
> >
> > Therefore, if the callback receives some data that it cannot handle
> > (either because the receive buffer has not been set up yet or because it
> > would not fit into the receive buffer) and we have to ignore it, we
> > still have to report that the data has been handled.
> >
> > Obviously, this should not happen normally. But it does happen at least
> > for FTP connections where some data (that we do not expect) may be
> > generated when the connection is established.
>
> Just to make sure, we aren't losing data by reporting this value, but
> merely letting curl know that our callback has "dealt" with the data, so
> that we don't error out, in order to get a second chance at the same
> data later on?
>
> Reviewed-by: Eric Blake <eblake@redhat.com>
>
> But given that it undoes 38bbc0a, I'd rather that it gets reviewed by
> Matthew and/or tested by Richard.
In that case, I guess we should CC them. (Hereby done.)
Kevin
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2016-10-26 9:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-25 2:54 [Qemu-devel] [PATCH 0/4] block/curl: Fix FTP Max Reitz
2016-10-25 2:54 ` [Qemu-devel] [PATCH 1/4] block/curl: Use BDRV_SECTOR_SIZE Max Reitz
2016-10-25 18:31 ` Eric Blake
2016-10-26 14:39 ` Max Reitz
2016-10-26 9:31 ` Richard W.M. Jones
2016-10-25 2:54 ` [Qemu-devel] [PATCH 2/4] block/curl: Fix return value from curl_read_cb Max Reitz
2016-10-25 18:37 ` Eric Blake
2016-10-26 9:17 ` Kevin Wolf [this message]
2016-11-01 9:58 ` Matthew Booth
2016-10-26 14:43 ` Max Reitz
2016-10-26 9:38 ` Richard W.M. Jones
2016-10-25 2:54 ` [Qemu-devel] [PATCH 3/4] block/curl: Remember all sockets Max Reitz
2016-10-25 2:54 ` [Qemu-devel] [PATCH 4/4] block/curl: Do not wait for data beyond EOF Max Reitz
2016-10-26 9:44 ` [Qemu-devel] [PATCH 0/4] block/curl: Fix FTP Richard W.M. Jones
2016-11-15 3:47 ` Jeff Cody
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=20161026091737.GH4758@noname.str.redhat.com \
--to=kwolf@redhat.com \
--cc=eblake@redhat.com \
--cc=jcody@redhat.com \
--cc=mbooth@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=rjones@redhat.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;
as well as URLs for NNTP newsgroup(s).