From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFvIr-0001QO-8a for qemu-devel@nongnu.org; Thu, 16 Jul 2015 22:23:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFvIn-0003gI-Ng for qemu-devel@nongnu.org; Thu, 16 Jul 2015 22:23:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFvIn-0003fn-IW for qemu-devel@nongnu.org; Thu, 16 Jul 2015 22:23:05 -0400 References: From: Paolo Bonzini Message-ID: <55A866FF.2080300@redhat.com> Date: Fri, 17 Jul 2015 04:22:55 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Commit 812c1057f, Handle G_IO_HUP in tcp_chr_read for tcp chardev, broke CloudStack List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nils Carlson , liangshunbin@jovaunn.com, qemu-devel@nongnu.org, batuzovk@ispras.ru, a.motakis@virtualopensystems.com, n.nikolaev@virtualopensystems.com, mst@redhat.com, zodiac@ispras.ru, amit.shah@redhat.com On 17/07/2015 00:51, Nils Carlson wrote: > > The commit 812c1057f, Handle G_IO_HUP in tcp_chr_read for tcp chardev, > broke CloudStack. CloudStack was relying on fire-and-forget style > messaging across a unix socket to the VM. Because the host "fires" the > message and then closes the socket a HUP is present on the line when the > VM starts reading the socket. Commit 812c1057f ensured that the socket > was checked for a HUP prior to calling recv, causing recv never to be > called by the VM and no data to be read. > > I've posted a patch, attached here, which moves the HUP detection to > after all data has been read, but only for Linux as I suspect windows > requires HUPs to be detected prior to reading data. I'm not sure, but I don't think this is the case. Why do you think Windows has this requirement? In any case, you should prepare a patch that has no Windows-specific paths and Cc Kirill Batuzov (batuzovk@ispras.ru) for him to test the patch. Alternatively I or you could test under Wine. > Amit also has concerns regarding the return values from the tcp_chr_read > function, which seem a bit odd as they are all TRUE, even for failure > paths. This is okay, I think, because the source is removed in tcp_chr_disconnect. Paolo