aboutsummaryrefslogtreecommitdiff
path: root/numa.c
diff options
context:
space:
mode:
authorMax Reitz <mreitz@redhat.com>2016-10-25 04:54:29 +0200
committerJeff Cody <jcody@redhat.com>2016-11-14 22:47:34 -0500
commit4e7676571bccb42dd49b5efbb91ac49077ea5197 (patch)
tree48ede80a4992d062e91581529eb99f5a86e88252 /numa.c
parent9054d9f6b00a3f0576b1a7310a3886d1783ad382 (diff)
downloadqemu-4e7676571bccb42dd49b5efbb91ac49077ea5197.zip
qemu-4e7676571bccb42dd49b5efbb91ac49077ea5197.tar.gz
qemu-4e7676571bccb42dd49b5efbb91ac49077ea5197.tar.bz2
block/curl: Fix return value from curl_read_cb
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. Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20161025025431.24714-3-mreitz@redhat.com Signed-off-by: Jeff Cody <jcody@redhat.com>
Diffstat (limited to 'numa.c')
0 files changed, 0 insertions, 0 deletions