From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKCk4-000807-Vu for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:35:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKCk3-0006Z0-Hi for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:35:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKCk3-0006Xw-8Y for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:35:19 -0400 Message-ID: <506F285F.1000405@redhat.com> Date: Fri, 05 Oct 2012 12:35:11 -0600 From: Eric Blake MIME-Version: 1.0 References: <1349460425-30601-1-git-send-email-coreyb@linux.vnet.ibm.com> <1349460425-30601-2-git-send-email-coreyb@linux.vnet.ibm.com> In-Reply-To: <1349460425-30601-2-git-send-email-coreyb@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5D21CCB6056009DFD4BD6690" Subject: Re: [Qemu-devel] [PATCH 1/4] monitor: Less restrictive fd matching for fd sets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Corey Bryant Cc: libvir-list@redhat.com, kwolf@redhat.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D21CCB6056009DFD4BD6690 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/05/2012 12:07 PM, Corey Bryant wrote: > Currently, in order to use a file descriptor that resides in an > fd set, the access mode flag of the qemu_open() call has to be > an exact match of the access mode flag of an fd in the requested > fd set. >=20 > This patch lightens up that restriction. For example, if QEMU > attempts to qemu_open() "/dev/fdset/2" with O_RDONLY or O_WRONLY, > and an fd in fd set 2 has O_RDWR, the call will now be successful. I was right for wondering if we'd need this, back when fdsets were first implemented. :) However... >=20 > Signed-off-by: Corey Bryant > --- > monitor.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/monitor.c b/monitor.c > index a0e3ffb..34a968c 100644 > --- a/monitor.c > +++ b/monitor.c > @@ -2304,7 +2304,8 @@ int monitor_fdset_get_fd(int64_t fdset_id, int fl= ags) > return -1; > } > =20 > - if ((flags & O_ACCMODE) =3D=3D (mon_fd_flags & O_ACCMODE))= { > + if ((mon_fd_flags & O_ACCMODE) =3D=3D O_RDWR || > + (mon_fd_flags & O_ACCMODE) =3D=3D (flags & O_ACCMODE))= { > return mon_fdset_fd->fd; > } Is this always the right fd to return? Suppose I create a set that contains two fds, one O_RDONLY and another O_RDWR; and that the current qemu_open() is requesting O_RDONLY. It feels like we would want to get the O_RDONLY fd returned, even if it comes later in the set, since it is nominally safer. That is, I wonder if this should really be implemented as an iteration over the set that selects the best possible match, where more than one fd can match, but at the end of the iteration, we have the closest match possible, rather than the first (possibly inexact) match. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig5D21CCB6056009DFD4BD6690 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/ iQEcBAEBCAAGBQJQbyhfAAoJEKeha0olJ0NqkGkIAK0vf4iIAvyLtchIbCe/h8rx 5VALbzEYTXHq3AO52WctZTiPxAyjNVU8ff3PDDfArxdx+fE65WMl3tmS25Fe4pJn ZN7jdDsvdM9sNBaTD+25kwrQctsKSF2zzqmtwJMLbe2OZwskhpJvFe7tUXkC8d+g P/ziEdvrkGZ+5oldLY2nR+LO8hJ2rVurylLFob8A+Awm6962Rnf9g/461Api1ekm NhSqABwexWn/CL4MDvg7mEHAWpWdBK9pwW2qTn6uzALG/9F9ntZCpvu6pNUjipv+ TUIf8r9Ir3QuiCvvCMn3hzVbUymDiEoxa2K5wUQQt2Wkjfp5btm9nSo+s27tG4Q= =Xqs+ -----END PGP SIGNATURE----- --------------enig5D21CCB6056009DFD4BD6690--