From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmKeJ-0000gq-Ve for qemu-devel@nongnu.org; Wed, 04 Jul 2012 04:09:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmKeE-0007F0-SP for qemu-devel@nongnu.org; Wed, 04 Jul 2012 04:09:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmKeE-0007En-KE for qemu-devel@nongnu.org; Wed, 04 Jul 2012 04:09:18 -0400 Message-ID: <4FF3FA22.6090400@redhat.com> Date: Wed, 04 Jul 2012 10:09:06 +0200 From: Kevin Wolf 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> In-Reply-To: <4FF3381D.40101@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 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: Corey Bryant 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 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. Kevin