From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3oq5-0005Ea-GN for qemu-devel@nongnu.org; Thu, 16 Jan 2014 10:26:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3opx-0006Ap-OH for qemu-devel@nongnu.org; Thu, 16 Jan 2014 10:26:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3opx-00069d-GG for qemu-devel@nongnu.org; Thu, 16 Jan 2014 10:26:29 -0500 Message-ID: <52D7FA1E.9040102@redhat.com> Date: Thu, 16 Jan 2014 08:26:22 -0700 From: Eric Blake MIME-Version: 1.0 References: <1389172376-30636-1-git-send-email-lilei@linux.vnet.ibm.com> <1389172376-30636-2-git-send-email-lilei@linux.vnet.ibm.com> In-Reply-To: <1389172376-30636-2-git-send-email-lilei@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ePeLEtQpp1hJsTlelh01BvXNCRJlBD3En" Subject: Re: [Qemu-devel] [PATCH 1/6] qemu-fd-exchange: provide common methods for exchange fd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lei Li , qemu-devel@nongnu.org Cc: pbonzini@redhat.com, mohan@in.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ePeLEtQpp1hJsTlelh01BvXNCRJlBD3En Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/08/2014 02:12 AM, Lei Li wrote: > Signed-off-by: Lei Li > --- > include/qemu/fd-exchange.h | 25 +++++++++++ > util/Makefile.objs | 1 + > util/qemu-fd-exchange.c | 97 ++++++++++++++++++++++++++++++++++++= ++++++++ > 3 files changed, 123 insertions(+), 0 deletions(-) > create mode 100644 include/qemu/fd-exchange.h > create mode 100644 util/qemu-fd-exchange.c >=20 > diff --git a/include/qemu/fd-exchange.h b/include/qemu/fd-exchange.h > new file mode 100644 > index 0000000..6929026 > --- /dev/null > +++ b/include/qemu/fd-exchange.h > @@ -0,0 +1,25 @@ > +/* > + * Internel common methods for exchange of FD s/Internel/Internal/ > +++ b/util/qemu-fd-exchange.c > @@ -0,0 +1,97 @@ > +/* > + * Internel common methods for exchange of FD and again. > +ssize_t qemu_send_with_fd(int sockfd, int passed_fd, > + const void *buf, size_t len) > +{ > + struct msghdr msg; > + struct iovec iov; > + struct cmsghdr *cmsg; > + union MsgControl msg_control; > + int retval; > + > + iov.iov_base =3D (int *)buf; > + iov.iov_len =3D len; > + > + memset(&msg, 0, sizeof(msg)); > + msg.msg_iov =3D &iov; > + msg.msg_iovlen =3D len; > + msg.msg_control =3D &msg_control; > + msg.msg_controllen =3D sizeof(msg_control); > + > + if (passed_fd < 0) { > + *(int *)buf =3D passed_fd; Is it safe to assume that buf is aligned well enough to be casting it to int* then dereferencing it? Why not just type the parameter correctly to begin with? And why are you even writing into the caller's buffer when they pass a negative fd, but leaving it alone when they pass a non-negative fd? > +ssize_t qemu_recv_with_fd(int sockfd, int *passed_fd, > + void *buf, size_t len) > +{ > + struct iovec iov; > + struct msghdr msg; > + struct cmsghdr *cmsg; > + union MsgControl msg_control; > + int retval; > + int data =3D *(int *)buf; Again, why not type buf correctly, since otherwise you risk a user passing in a buffer that is unsuitably aligned for dereferencing as an int pointer. > + > + iov.iov_base =3D buf; > + iov.iov_len =3D len; > + > + memset(&msg, 0, sizeof(msg)); > + msg.msg_iov =3D &iov; > + msg.msg_iovlen =3D 1; > + msg.msg_control =3D &msg_control; > + msg.msg_controllen =3D sizeof(msg_control); > + Should you take advantage of Linux' ability to use MSG_CMSG_CLOEXEC to guarantee the received fd is atomically marked cloexec when possible? > + do { > + retval =3D recvmsg(sockfd, &msg, 0); > + } while (retval < 0 && errno =3D=3D EINTR); > + > + if (retval <=3D 0) { > + return retval; > + } > + > + if (data !=3D *(int *)buf) { > + *passed_fd =3D data; > + return 0; > + } > + > + for (cmsg =3D CMSG_FIRSTHDR(&msg); cmsg; cmsg =3D CMSG_NXTHDR(&msg= , cmsg)) { > + if (cmsg->cmsg_len !=3D CMSG_LEN(sizeof(int)) || > + cmsg->cmsg_level !=3D SOL_SOCKET || > + cmsg->cmsg_type !=3D SCM_RIGHTS) { > + continue; > + } > + > + memcpy(passed_fd, CMSG_DATA(cmsg), sizeof(*passed_fd)); > + return 0; > + } And even when MSG_CMSG_CLOEXEC is not available, shouldn't you ensure that cloexec is set after the fact? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ePeLEtQpp1hJsTlelh01BvXNCRJlBD3En 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJS1/oeAAoJEKeha0olJ0Nqgw0H/1TDkcs/h3KKcb+WBfpKBAZj 19zoDmNpZwxvbJECp6M6kYfDKCbfnf//G8IWC3wuho4n4Hvv5zGz6Bz3VPN2DRSj Y/3iIsy6zuiDhDDX/XuHdhaE+rl9EiVJXmqTqbbjj7PA5zmq6NtwHaKtufX/Lqkx wuEugeWFoZpzkUY8boqvS7EprFsC3mZJWDmproX2SMyBH1eV3mkruimUmangri3s MvWCAg8dQEWq6mfxW+Qs234cG3XvdDIdWw5QNhEW19uE0QoEW4K3VS8+5vGpQhuj voPOZMhwNMuEKjMgFvsu8fhIKG2FQ/uJlV3mkRfGuVRJmAEXgeXpRxB3DLHwzzk= =zWfy -----END PGP SIGNATURE----- --ePeLEtQpp1hJsTlelh01BvXNCRJlBD3En--