From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Smnft-0007KF-4y for qemu-devel@nongnu.org; Thu, 05 Jul 2012 11:09:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Smnfm-0007lV-6q for qemu-devel@nongnu.org; Thu, 05 Jul 2012 11:08:56 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:37840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Smnfm-0007ke-0U for qemu-devel@nongnu.org; Thu, 05 Jul 2012 11:08:50 -0400 Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 5 Jul 2012 09:08:44 -0600 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 8ADA519D80BF for ; Thu, 5 Jul 2012 15:07:22 +0000 (WET) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q65F6x6o277144 for ; Thu, 5 Jul 2012 09:07:01 -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 q65F6wMw004870 for ; Thu, 5 Jul 2012 09:06:59 -0600 Message-ID: <4FF5AD90.8000305@linux.vnet.ibm.com> Date: Thu, 05 Jul 2012 11:06:56 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1340390174-7493-1-git-send-email-coreyb@linux.vnet.ibm.com> <20120626091004.GA14451@redhat.com> <4FE9A0F0.2050809@redhat.com> <20120626175045.2c7011b3@doriath.home> <4FEA37A9.10707@linux.vnet.ibm.com> <4FEA3D9C.8080205@redhat.com> <4FF21A67.8010100@linux.vnet.ibm.com> <4FF31265.1000308@linux.vnet.ibm.com> <4FF316C9.5020100@redhat.com> <4FF31CFD.7030508@linux.vnet.ibm.com> <4FF325C8.4060401@redhat.com> <4FF33004.5030909@linux.vnet.ibm.com> <4FF33349.10404@redhat.com> <4FF3381D.40101@linux.vnet.ibm.com> <4FF3FA22.6090400@redhat.com> In-Reply-To: <4FF3FA22.6090400@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, libvir-list@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , pbonzini@redhat.com, Eric Blake On 07/04/2012 04:09 AM, Kevin Wolf wrote: > Am 03.07.2012 20:21, schrieb Corey Bryant: >> On 07/03/2012 02:00 PM, Eric Blake wrote: >>> On 07/03/2012 11:46 AM, Corey Bryant wrote: >>> >>>> >>>> Yes, I think adding a +1 to the refcount for the monitor makes sense. >>>> >>>> I'm a bit unsure how to increment the refcount when a monitor reconnects >>>> though. Maybe it is as simple as adding a +1 to each fd's refcount when >>>> the next QMP monitor connects. >>> >>> Or maybe delay a +1 until after a 'query-fds' - it is not until the >>> monitor has reconnected and learned what fds it should be aware of that >>> incrementing the refcount again makes sense. But that would mean making >>> 'query-fds' track whether this is the first call since the monitor >>> reconnected, as it shouldn't normally increase refcounts. >> >> This doesn't sound ideal. > > Yes, it's less than ideal. > >>> The other alternative is that the monitor never re-increments a >>> refcount. Once a monitor disconnects, that fd is lost to the monitor, >>> and a reconnected monitor must pass in a new fd to be re-associated with >>> the fdset. In other words, the monitor's use of an fd is a one-way >>> operation, starting life in use but ending at the first disconnect or >>> remove-fd. >> >> I would vote for this 2nd alternative. As long as we're not introducing >> an fd leak. And I don't think we are if we decrement the refcount on >> remove-fd or on QMP disconnect. > > In fact, I believe this one is even worse. I can already see hacks like > adding a dummy FD with invalid flags and removing it again just to > regain control over the fdset... > > You earlier suggestion made a lot of sense to me: Whenever a new QMP > monitor is connected, increase the refcount. That is, as long as any > monitor is there, don't drop any fdsets unless explicitly requested via QMP. Ok. So refcount would be incremented (for the fd or fdset, whatever we decide on) when QMP reconnects. I'm assuming we wouldn't wait until after a query-fds call. I'll go with this approach until someone objects. -- Regards, Corey