From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoEa9-0003ky-5Q for qemu-devel@nongnu.org; Mon, 09 Jul 2012 10:05:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SoEa2-0004Zi-KW for qemu-devel@nongnu.org; Mon, 09 Jul 2012 10:04:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23723) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoEa2-0004ZP-CF for qemu-devel@nongnu.org; Mon, 09 Jul 2012 10:04:50 -0400 Date: Mon, 9 Jul 2012 11:05:10 -0300 From: Luiz Capitulino Message-ID: <20120709110510.12214347@doriath.home> In-Reply-To: <4FF5AD90.8000305@linux.vnet.ibm.com> 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> <4FF5AD90.8000305@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Kevin Wolf , aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, libvir-list@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, Eric Blake On Thu, 05 Jul 2012 11:06:56 -0400 Corey Bryant wrote: > > > 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'm not sure this is a good idea because we will leak fds if the client forgets about the fds when re-connecting (ie. it was restarted) or if a different client connects to QMP. If we really want to do that, I think that the right way of doing this is to add a command for clients to re-again ownership of the fds on reconnection. But to be honest, I don't fully understand why this is needed.