aboutsummaryrefslogtreecommitdiff
path: root/hw/intc
diff options
context:
space:
mode:
authorAnton Nefedov <anton.nefedov@virtuozzo.com>2017-02-02 17:26:29 +0300
committerPaolo Bonzini <pbonzini@redhat.com>2017-02-16 14:06:55 +0100
commitb0a335e351103bf92f3f9d0bd5759311be8156ac (patch)
tree549a74beeed5787e0d6b0535406c9f955f27c86c /hw/intc
parenta3fd46152ed27e795871e9e5e73ef9c90a16e25e (diff)
qemu-char: socket backend: disconnect on write error
Socket backend read handler should normally perform a disconnect, however the read handler may not get a chance to run if the frontend is not ready (qemu_chr_be_can_write() == 0). This means that in virtio-serial frontend case if - the host has disconnected (giving EPIPE on socket write) - and the guest has disconnected (-> frontend not ready -> backend will not read) - and there is still data (frontend->backend) to flush (has to be a really tricky timing but nevertheless, we have observed the case in production) This results in virtio-serial trying to flush this data continiously forming a busy loop. Solution: react on write error in the socket write handler. errno is not reliable after qio_channel_writev_full(), so we may not get the exact EPIPE, so disconnect on any error but QIO_CHANNEL_ERR_BLOCK which io_channel_send_full() converts to errno EAGAIN. We must not disconnect right away though, there still may be data to read (see 4bf1cb0). Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Daniel P. Berrange <berrange@redhat.com> CC: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1486045589-8074-1-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'hw/intc')
0 files changed, 0 insertions, 0 deletions