From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NiXVi-0007Ec-6t
	for qemu-devel@nongnu.org; Fri, 19 Feb 2010 13:23:30 -0500
Received: from [199.232.76.173] (port=44337 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NiXVh-0007EF-Mj
	for qemu-devel@nongnu.org; Fri, 19 Feb 2010 13:23:29 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <eswierk@aristanetworks.com>)
	id 1NiXVg-0000KS-3v
	for qemu-devel@nongnu.org; Fri, 19 Feb 2010 13:23:29 -0500
Received: from ey-out-1920.google.com ([74.125.78.150]:21893)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <eswierk@aristanetworks.com>) id 1NiXVf-0008Qu-N3
	for qemu-devel@nongnu.org; Fri, 19 Feb 2010 13:23:27 -0500
Received: by ey-out-1920.google.com with SMTP id 3so260031eyh.14
	for <qemu-devel@nongnu.org>; Fri, 19 Feb 2010 10:21:42 -0800 (PST)
MIME-Version: 1.0
Date: Fri, 19 Feb 2010 10:21:41 -0800
Message-ID: <9ae48b021002191021r7e7afb4bxd1d47624e07db1e9@mail.gmail.com>
From: Ed Swierk <eswierk@aristanetworks.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Qemu-devel] getfd monitor command broken
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Commit c62313bbdc48f72e93fa8196f2fff96ba35e4e9d seems to have broken
the getfd monitor command in qemu 0.12.

tcp_chr_read() calls tcp_chr_recv(), which checks whether the received
message includes an SCM_RIGHTS header, and if so, stores the received
fd in the CharDriverState struct. tcp_chr_read() passes the received
data to the monitor via qemu_chr_read(), and then closes the stored
fd.

Previously, tcp_chr_read() would receive the entire getfd command in
one message (perhaps by sheer luck), allowing the monitor to call
qemu_chr_get_msgfd() to obtain the stored fd before it disappeared.
Now that tcp_chr_read() receives only 1 byte at a time, the stored fd
vanishes when it receives byte 2.

I'm too confused by this control flow to suggest a proper solution,
but commenting out the "if (s->msgfd != -1)" block in tcp_chr_read()
at least makes the problem go away.

--Ed