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>
GIOCondition cond,
void *opaque);
+static int tcp_chr_read_poll(void *opaque);
+static void tcp_chr_disconnect(Chardev *chr);
+
/* Called with chr_write_lock held. */
static int tcp_chr_write(Chardev *chr, const uint8_t *buf, int len)
{
s->write_msgfds_num = 0;
}
+ if (ret < 0 && errno != EAGAIN) {
+ if (tcp_chr_read_poll(chr) <= 0) {
+ tcp_chr_disconnect(chr);
+ return len;
+ } /* else let the read handler finish it properly */
+ }
+
return ret;
} else {
/* XXX: indicate an error ? */