From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVVqd-00040q-Lh for qemu-devel@nongnu.org; Tue, 10 Mar 2015 21:54:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVVqZ-0007Hc-E0 for qemu-devel@nongnu.org; Tue, 10 Mar 2015 21:54:11 -0400 Received: from ozlabs.org ([2401:3900:2:1::2]:44966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVVqZ-0007GJ-2V for qemu-devel@nongnu.org; Tue, 10 Mar 2015 21:54:07 -0400 Date: Wed, 11 Mar 2015 12:51:57 +1100 From: David Gibson Message-ID: <20150311015157.GL11973@voom.redhat.com> References: <1424883128-9841-1-git-send-email-dgilbert@redhat.com> <1424883128-9841-9-git-send-email-dgilbert@redhat.com> <20150310025627.GI30335@voom.fritz.box> <20150310133557.GG2338@work-vm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="20XocjIeMTCm4X0r" Content-Disposition: inline In-Reply-To: <20150310133557.GG2338@work-vm> Subject: Re: [Qemu-devel] [PATCH v5 08/45] Return path: socket_writev_buffer: Block even on non-blocking fd's List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, qemu-devel@nongnu.org, amit.shah@redhat.com, pbonzini@redhat.com, yanghy@cn.fujitsu.com --20XocjIeMTCm4X0r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 10, 2015 at 01:35:58PM +0000, Dr. David Alan Gilbert wrote: > * David Gibson (david@gibson.dropbear.id.au) wrote: > > On Wed, Feb 25, 2015 at 04:51:31PM +0000, Dr. David Alan Gilbert (git) = wrote: > > > From: "Dr. David Alan Gilbert" > > >=20 > > > The return path uses a non-blocking fd so as not to block waiting > > > for the (possibly broken) destination to finish returning a message, > > > however we still want outbound data to behave in the same way and blo= ck. > >=20 > > It's not clear to me from this description exactly where the situation > > is that you need to write to the non-blocking socket. Is it on the > > source or the destination? If the source, why are you writing to the > > return path? If the destination, why are you marking the outgoing > > return path as non-blocking? >=20 > My understanding is that the semantics of set_nonblock() are to > set non-blocking on all operations on the transport associated with > the fd - and that it's true even if you dup() the fd; and so if you > set non-blocking in one direction you get it in the other direction as we= ll. Ah.. yes, I think you're right. > The (existing) destination side sets non-block (see process_incoming_migr= ation > in migration.c), and so it gets non-blocking on the incoming data stream,= but > that has the side effect that it's also going to be non-blocking on > the destinations writes to the reverse-path; thus we need to be able > to safely do writes from the destination reverse-path. >=20 > The text is out of date, back in v2 the source used to use non-blocking > for the return-path, but we managed to kill that off by using a thread > for the return path in the source. >=20 > How about changing the text to: > -------- > The destination sets the fd to non-blocking on incoming migrations; > this also affects the return path from the destination, and thus we > need to make sure we can safely write to the return path. Yes, I think that makes it clearer. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --20XocjIeMTCm4X0r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU/5+9AAoJEGw4ysog2bOSJlsP/iFMa0u+Oyj8zNIDexhFGaGB jWuwqHslyxYweFLC3UNBu0CwmZJikphNc4r7OQsxad3fT10JE+y3KpuMQubpzGXn Qo0mG41AI1KRAoaQHjqDdJv3u3FFZWmNdN/+bXUzJlMukKIfYhNsayMizFE54EsX D6LLXN7j0O2TIrnxYS9AUYHZSEj+7SxWy9Wk709Px9TIHXyISQ5CXh6RagW192Qa OkPaTUfiqdcBnY+vxzrW39rr8GgLMRL3ZuNWNT3EnAjaWzpWXguC3emUhayQnDfZ DbQQHr8/ezmYnkbdHMz/cW+Ap3ogOYgN5QES/JjueAzz13sxr8QmIQvl1RXhnzkt g2pVh9HEpruT9ApM+7PwSUptZdLnXts6WQJlKerTZlhJiVTGznXh6S4DTzZ3ja2v VdtREZEsXM9PjsfcE1E7HGCwjtCM8Hv5dwymFbVnRuBVPdzJ8Bj1wcYV0j75wW57 r+E3xmoInfsiSOgzYCSEDuAgSejj+2CJP6lFqQkhTZSHAv/QFpBzm/3X/Q5CrNly NsloWdgRed3qFZkSWLQg5OJl73QslsAnHqam4onz2ccOyv3r9q1DfMRMmJp30sfb E+gyj+MJEPaZ40/RqAhzcXpEn+KugxYWq61KbvJLKlEfjIP9Xfftn7ngqe6Fq49G 5lPsWcwge77TTZXu9Am0 =3T/g -----END PGP SIGNATURE----- --20XocjIeMTCm4X0r--