[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Commit 812c1057f, Handle G_IO_HUP in tcp_chr_read for t
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] Commit 812c1057f, Handle G_IO_HUP in tcp_chr_read for tcp chardev, broke CloudStack |
Date: |
Fri, 17 Jul 2015 04:22:55 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 |
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
(address@hidden) 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