From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSpDy-0003QP-MU for qemu-devel@nongnu.org; Mon, 08 Feb 2016 12:03:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSpDx-0006nk-SS for qemu-devel@nongnu.org; Mon, 08 Feb 2016 12:03:42 -0500 Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233]:35387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSpDx-0006nM-M4 for qemu-devel@nongnu.org; Mon, 08 Feb 2016 12:03:41 -0500 Received: by mail-wm0-x233.google.com with SMTP id c200so25247766wme.0 for ; Mon, 08 Feb 2016 09:03:41 -0800 (PST) Sender: Paolo Bonzini From: Paolo Bonzini Date: Mon, 8 Feb 2016 18:03:06 +0100 Message-Id: <1454950999-64128-16-git-send-email-pbonzini@redhat.com> In-Reply-To: <1454950999-64128-1-git-send-email-pbonzini@redhat.com> References: <1454950999-64128-1-git-send-email-pbonzini@redhat.com> Subject: [Qemu-devel] [PULL 15/28] char: fix repeated registration of tcp chardev I/O handlers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org From: "Daniel P. Berrange" In previous commit: commit f2001a7e0555b66d6db25a3ff1801540814045bb Author: Daniel P. Berrange Date: Tue Jan 19 11:14:30 2016 +0000 char: don't assume telnet initialization will not block The code which writes the telnet initialization sequence moved to an event loop callback. If the TCP chardev is opened as a server in blocking mode (ie -serial telnet:0.0.0.0:3000,server,wait) this results in a state where the TCP chardev is connected, but not yet ready to send/recv data when virtual hardware is created. When the virtual hardware initialization registers its chardev callbacks, it triggers tcp_chr_update_read_handler, which will add I/O watches to the connection. When the telnet initialization finally runs, it will then call tcp_chr_connect to finish the connection setup. This will in turn add I/O watches to the connection too. There are now two sets of I/O watches registered on the same connection. This ultimately causes data loss on the connection, for example, when typing into the telnet console only every second byte is echoed back to the client. The same flaw can affect channels running with TLS encryption too, since they also have delayed connection setup completion. The fix is to update tcp_chr_update_read_handler so that it avoids registering watches if the connection is not fully setup yet. Signed-off-by: Daniel P. Berrange Message-Id: <1454939707-10869-1-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini --- qemu-char.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/qemu-char.c b/qemu-char.c index 1fbccf0..84eb8a1 100644 --- a/qemu-char.c +++ b/qemu-char.c @@ -2858,6 +2858,10 @@ static void tcp_chr_update_read_handler(CharDriverState *chr) { TCPCharDriver *s = chr->opaque; + if (!s->connected) { + return; + } + remove_fd_in_watch(chr); if (s->ioc) { chr->fd_in_tag = io_add_watch_poll(s->ioc, -- 1.8.3.1