From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOV83-0004wT-N4 for qemu-devel@nongnu.org; Wed, 17 Oct 2012 11:01:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOV7w-0001cf-Qm for qemu-devel@nongnu.org; Wed, 17 Oct 2012 11:01:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOV7w-0001cO-IA for qemu-devel@nongnu.org; Wed, 17 Oct 2012 11:01:44 -0400 Message-ID: <507EC84E.30106@redhat.com> Date: Wed, 17 Oct 2012 09:01:34 -0600 From: Eric Blake MIME-Version: 1.0 References: <1350411046-2453-1-git-send-email-coreyb@linux.vnet.ibm.com> <507E3103.1020202@redhat.com> <507EBA60.9000000@redhat.com> In-Reply-To: <507EBA60.9000000@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF3850A78A4CA9D15E87ADF86" 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, Corey Bryant , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF3850A78A4CA9D15E87ADF86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/17/2012 08: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=3D3,set=3D1 -add-fd fd=3D4,set=3D2 4<&- >> >> where the dup(3) will populate fd 4 prior to the point where we get to= >> process the -add-fd fd=3D4 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). >=20 > 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". Overnight, I realized we do have one potential safety valve: we are guaranteed that any fd inherited by the exec() of qemu-kvm has FD_CLOEXEC clear, and we also strive to have qemu open/dup all of its internal fds with FD_CLOEXEC set. Therefore, it may be worth a sanity check of fcntl(F_GETFD) to see if FD_CLOEXEC is set, and if so, the user must have failed to pass in the fd, and we are now looking at a qemu internal fd, and should therefore report failure. But I'm not sure if it's worth the extra code. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigF3850A78A4CA9D15E87ADF86 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://www.enigmail.net/ iQEcBAEBCAAGBQJQfshOAAoJEKeha0olJ0NqhGEH/0cKFl+I86hTm42pZGosFSBK w3Nokr5ob2i7IdDhcjyKeX5XoNkldJpT815djvlCMBk8xfdXNK7jYLfiiM2TdU8L NYwqv90MslA4WNS+eHDkAhD9R1GL9/4r1JljXvxigv2Ja9TVEs/ZmL891bgHEXPl 9m8bZIVvoOnJIcxCGV75lXa9QgLUrfL4XSsREaJ25DYoTx20BUVPWTgczrxWdSfT UjGEqCPQ5BOpnb6GDuOITn6BfPPtCCGo6GqkvB7VdvqSLzHo5LhqfME44sG0kV/t ZPYG4lIdXMBdsV4r2cVsOOh4juVGE63mCLjE90eaYPIVjEh/srJoauZcYJ221GA= =PKbo -----END PGP SIGNATURE----- --------------enigF3850A78A4CA9D15E87ADF86--