summaryrefslogtreecommitdiffstats
path: root/qemu-char.c
diff options
context:
space:
mode:
authorDaniel P. Berrange <berrange@redhat.com>2016-02-12 14:46:50 +0000
committerTimothy Pearson <tpearson@raptorengineering.com>2019-11-29 19:45:28 -0600
commit3f88b9dd52c4fd55745abde46c199ab2b2c5739e (patch)
treef2c365a991ed6af363758c0282c25c3bef8da5ba /qemu-char.c
parent1896c3f98b5723fb98e7d0894c9a1fdf203c6fce (diff)
downloadhqemu-3f88b9dd52c4fd55745abde46c199ab2b2c5739e.zip
hqemu-3f88b9dd52c4fd55745abde46c199ab2b2c5739e.tar.gz
char: fix handling of QIO_CHANNEL_ERR_BLOCK
If io_channel_send_full gets QIO_CHANNEL_ERR_BLOCK it and has already sent some of the data, it should return that amount of data, not EAGAIN, as that would cause the caller to re-try already sent data. Unfortunately due to a previous rebase conflict resolution error, the code for dealing with this was in the wrong part of the conditional, and so mistakenly ran on other I/O errors. This be seen running qemu-system-x86_64 -monitor stdio and entering 'info mtree', when running on a slow console (eg a slow remote ssh session). The monitor would get into an indefinite loop writing the same data until it managed to send it all without getting EAGAIN. Reported-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1455288410-27046-1-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'qemu-char.c')
-rw-r--r--qemu-char.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/qemu-char.c b/qemu-char.c
index 00caf65..ad11b75 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -896,13 +896,13 @@ static int io_channel_send_full(QIOChannel *ioc,
ioc, &iov, 1,
fds, nfds, NULL);
if (ret == QIO_CHANNEL_ERR_BLOCK) {
- errno = EAGAIN;
- return -1;
- } else if (ret < 0) {
if (offset) {
return offset;
}
+ errno = EAGAIN;
+ return -1;
+ } else if (ret < 0) {
errno = EINVAL;
return -1;
}
OpenPOWER on IntegriCloud