From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sfchh-0001ak-7z for qemu-devel@nongnu.org; Fri, 15 Jun 2012 16:01:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sfchf-0006Y4-Bk for qemu-devel@nongnu.org; Fri, 15 Jun 2012 16:01:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sfchf-0006XX-38 for qemu-devel@nongnu.org; Fri, 15 Jun 2012 16:01:07 -0400 Message-ID: <4FDB9477.9060709@redhat.com> Date: Fri, 15 Jun 2012 14:00:55 -0600 From: Eric Blake MIME-Version: 1.0 References: <1339689305-27031-1-git-send-email-coreyb@linux.vnet.ibm.com> <1339689305-27031-4-git-send-email-coreyb@linux.vnet.ibm.com> <4FDB51E8.8060406@redhat.com> <4FDB7C1B.8020802@linux.vnet.ibm.com> <4FDB82F9.8020708@redhat.com> <4FDB8AAC.3030002@linux.vnet.ibm.com> In-Reply-To: <4FDB8AAC.3030002@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig95669FE02B4AE5CB19AEBC29" Subject: Re: [Qemu-devel] [PATCH v3 3/5] osdep: Enable qemu_open to dup pre-opened 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, lcapitulino@redhat.com, pbonzini@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig95669FE02B4AE5CB19AEBC29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/15/2012 01:19 PM, Corey Bryant wrote: >>> There are some flags that I don't think we'll be able to change. For= >>> example: O_RDONLY, O_WRONLY, O_RDWR. I assume libvirt would open all= >>> files O_RDWR. >> >> I think we need to check all of them and fail qemu_open() if they don'= t >> match. Those that qemu can change, should be just changed, of course. >> >=20 > Ok. I remember a scenario where QEMU opens a file read-only (perhaps t= o > check headers and determine the file format) before re-opening it > read-write. Perhaps this is only when format=3D isn't specified with > -drive. I'm thinking we may need to change flags to read-write where > they used to be read-only, in some circumstances. In those situations, libvirt would pass fd with O_RDWR, and qemu_open() would be fine requesting O_RDONLY the first time (subset is okay), and O_RDWR the second time. Where you have to error out is where libvirt passes O_RDONLY but qemu wants O_RDWR, and so forth. >> >> In which scenario would any client break if we set FD_CLOEXEC? I don't= >> think compatibility means we can't fix any bugs. >> >=20 > I don't know if it breaks any client. Maybe it's not a compatibility > error. It dopes change behavior down the line though. If you think > it's ok to set FD_CLOEXEC for getfd too, then I'm happy to do it. The only case that a client might break is if there were a way to pass an fd into qemu and then intentionally see that fd in a child process of qemu. But in the case of 'migrate fd:nnn', you aren't spawning a child process, and even in the case of 'migrate exec:command' (which libvirt no longer uses if fd:nnn works), I don't see how the client could have ever intentionally tried to use 'getfd' in advance to pass an extra fd for use inside the 'exec:command' child. Besides, before 'pass-fd' was around, how would the management app triggering the 'exec:command' even know what fd number would accidentally be inherited into the exec:command child? I think it is pretty much a straight bug-fix for 'getfd' to always set FD_CLOEXEC, and preferably set it atomically via MSG_CMSG_CLOEXEC. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig95669FE02B4AE5CB19AEBC29 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/ iQEcBAEBCAAGBQJP25R3AAoJEKeha0olJ0NqB6AIAIQF+jdBjELNE9S8Cuj5Egmn qMi1HPgI28OoAZg16+1PsQB9zgk+X6SaoDbsg47aTA3FZc5kTcVeYfEWkeaY9suv Kc40M0hw+AEi+dIghuD3k+7oJhG0hF+RjyQLyu568V6c7x0c8XyXXvrr7WiapN2e 8nkHutIWr7bk5Nn9Vdvihw/Np4Yn2HNkOlgkWGXixjqhvL6BPelnqZGW/d21JU/E B3vtuyt3xrbxa3TRsdeBOvxYZhkj73kY4XPvAC46STBpXS9Oz1uEdnZVCdwG00lu aCn5+58On2Jvpp8HKZ7DegWoziV4RO++7OAKwVUr7yQv1UmMXZA+i/EEBIRtKgY= =+owf -----END PGP SIGNATURE----- --------------enig95669FE02B4AE5CB19AEBC29--