From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmpQH-00059V-GQ for qemu-devel@nongnu.org; Thu, 05 Jul 2012 13:01:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmpQB-00054P-4u for qemu-devel@nongnu.org; Thu, 05 Jul 2012 13:00:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmpQA-000549-Ry for qemu-devel@nongnu.org; Thu, 05 Jul 2012 13:00:51 -0400 Message-ID: <4FF5C811.6040605@redhat.com> Date: Thu, 05 Jul 2012 11:00:01 -0600 From: Eric Blake 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> <4FF3F806.7020307@redhat.com> <4FF5A331.9030108@linux.vnet.ibm.com> <4FF5A9D9.7080607@redhat.com> <4FF5C24E.9010008@linux.vnet.ibm.com> In-Reply-To: <4FF5C24E.9010008@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig06F375C780C6613D436F923A" 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, Luiz Capitulino , pbonzini@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig06F375C780C6613D436F923A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/05/2012 10:35 AM, Corey Bryant wrote: > 1. client calls 'add-fd', qemu is now tracking fd=3D4 in fdset1 with > refcount of 0; fd=3D4's in-use flag is turned on > 2. client calls 'device-add' with /dev/fdset/1 as the backing filename,= > so qemu_open() increments the refcount of fdset1 to 1 > 3. client crashes, so all tracked fds are visited; fd=3D4 had not yet b= een > passed to 'remove-fd', so it's in-use flag is on; in-use flag is turne= d > off and fd=3D4 is left open because it is still in use by the block dev= ice > (refcount is 1) > 4. client re-establishes QMP connection, so all tracked fds are visited= , > and in-use flags are turned back on; 'query-fds' lets client learn abou= t > fd=3D4 still being open as part of fdset1 This says that an in-use fd comes back into use after a crash... >=20 > 1. client calls 'add-fd', qemu is now tracking fd=3D4 in fdset1 with > refcount of 0; fd=3D4's in-use flag is turned on > 2. client calls 'device-add' with /dev/fdset/1 as the backing filename,= > so qemu_open() increments the refcount of fdset1 to 1 > 3. client calls 'remove-fd fdset=3D1 fd=3D4', so qemu marks fd=3D4 as n= o > longer in-use by the monitor, and is left open because it is in use by > the block device (refcount is 1) > 4. client crashes, so all tracked fds are visited; fd=3D4 is not in-use= > but refcount is 1 so it is not closed 5. client re-establishes QMP connection, so all tracked fds are visited. What happens to the fd=3D4 in-use flag? =2E..but what are the semantics here? If we _always_ turn the in-use flag back on, then that says that even though libvirt successfully asked to close the fd, the reconnection means that libvirt once again has to ask to close things. If we _never_ turn the in-use flag back on, then we've broken the first case above where we want an in-use fd to come back into use after a crash= =2E Maybe that argues for two flags per fd: an in-use flag (there is currently a monitor connection that can manipulate the fd, either because it passed in the fd or because it reconnected) and a removed flag (a monitor called remove-fd, and no longer wants to know about the fd, even if it crashes and reconnects). An fd is then closed when 'refcount =3D=3D 0 && (!inuse || removed)'. On monitor disconnect, the inuse flag is cleared, and on reconnect, it is set; but that does not impact the removed flag. And the 'query-fds' command would omit any fd with the 'removed' flag, even when the fd is still kept open internally thanks to the refcount being nonzero. But I'm definitely agreeing that tying the refcount to the set rather than to individual fds within the set makes sense; you still avoid the fd leak in that all fds in the set are closed when both the monitor has disavowed the set and when qemu_close() has finished using any of the fds= =2E --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig06F375C780C6613D436F923A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJP9cgRAAoJEKeha0olJ0NqeeoH/0ozWalSfFYhhFllhC9bXrGq ujDpnl7Quu/tyxUYj710XnTuuZdp/D23y5TCEq4vvZg/tYdH8uebc/LYTdvrQSQa 5WLIG7hZQ/YRcymQhwfMgocg2+/7Hgw79Pj6/ZhlgKQWAtEZKcdQcWHaunndFgrB wKZkaARR1olS56iFvpqioqePRiaEvPkEj31UG30CnRogfqsHDgpwcE5xhRJ+yiqy 9MLHxY9JYAbfM3DIvZ3TsJv5GkrEArvb33QGiCBYFdTUBBHoVw+WNBYigjh8ZL/x rMbKTiAFuzgd61DqAH8DuRbJiFEgU5/4zkqR/zddrTcoqALrHfQhI3JHwU8VI9M= =q/tq -----END PGP SIGNATURE----- --------------enig06F375C780C6613D436F923A--