From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOvBE-00074r-CN for qemu-devel@nongnu.org; Thu, 18 Oct 2012 14:50:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOvBC-0004aS-Ld for qemu-devel@nongnu.org; Thu, 18 Oct 2012 14:50:52 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:38259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOvBC-0004Zg-8n for qemu-devel@nongnu.org; Thu, 18 Oct 2012 14:50:50 -0400 Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 18 Oct 2012 12:50:48 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 24E43C40001 for ; Thu, 18 Oct 2012 12:50:44 -0600 (MDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9IIod5u227450 for ; Thu, 18 Oct 2012 12:50:42 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9IIocl3005976 for ; Thu, 18 Oct 2012 12:50:38 -0600 Message-ID: <50804F7C.9090209@linux.vnet.ibm.com> Date: Thu, 18 Oct 2012 14:50:36 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1350411046-2453-1-git-send-email-coreyb@linux.vnet.ibm.com> <507E3103.1020202@redhat.com> <507EBA60.9000000@redhat.com> <5080125C.5070107@linux.vnet.ibm.com> In-Reply-To: <5080125C.5070107@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 4/4] qemu-config: Add new -add-fd command line option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: libvir-list@redhat.com, qemu-devel@nongnu.org On 10/18/2012 10:29 AM, Corey Bryant wrote: > > > On 10/17/2012 10:02 AM, Kevin Wolf wrote: >> Am 17.10.2012 06:16, schrieb Eric Blake: >>> I'm still seeing the corner case of: >>> >>> qemu-kvm -add-fd fd=3,set=1 -add-fd fd=4,set=2 4<&- >>> >>> where the dup(3) will populate fd 4 prior to the point where we get to >>> process the -add-fd fd=4 command to notice that the user started >>> qemu-kvm with fd 4 closed, and thus qemu will silently proceed to use >>> the wrong fd. >>> >>> On the other hand, I'm not sure if that corner case is worth worrying >>> about, or if we just chalk it up to user stupidity (aka libvirt >>> programmer stupidity) if they did something like that (most likely, >>> because the management app forgot to clear FD_CLOEXEC before exec()ing >>> qemu-kvm). >> >> If you specify an FD number that isn't actually open when qemu is >> stared, you can get any FD that qemu opens internally. I think the >> correct answer to this problem is "then don't do that". >> > > I'd also say "then don't do that". Or maybe "why are you doing that?". > But I'm not opposed to closing a corner case if it's not cluttering the > code base. > >>> Hmm, this makes me wonder if I can do something crazy like: >>> >>> qemu-kvm -add-fd fd=4,set=1 -qmp /dev/fdset/1 >>> >>> to open a monitor on the fd I just passed in? >> >> I think so. At least on my side it was intended to allow this. >> >>> And what if so, what then >>> happens on that monitor if I request that fdset 1 be removed? >> >> The same as with block devices: The fd stays open until the monitor >> connection is closed. A closed monitor also triggers fd garbage >> collection, so at this point the original fd would be closed (well, >> assuming that you had only one monitor). >> >> Kevin >> > > True, but I think in this case we care more about the dup'd fd staying > open than the fd in the fdset. Remember that qemu_open() dups the fd > from the fd set. So assuming the open/close of the QMP fd occurs in > qemu_open()/qemu_close(), the QMP fd would be a dup of the fd that was > added to the fd set. So if remove-fd removed the fd from the fdset, or > it removed the entire fdset, the QMP fd would remain open until > qemu_close() was called. I'll try this out today to make sure but I > don't think this is an issue. > After digging into this some more it appears to be a non issue. Only qemu_open() and qemu_close() deal with fdsets. The QMP fd is created with qemu_socket(), not qemu_open(), so it doesn't deal with fdsets. The ensuing bind() call that specifies the path ends up failing with ENOENT because the actual path "/dev/fdset/1" doesn't exist: bind(unix:/dev/fdset/1): No such file or directory -- Regards, Corey Bryant