From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3sfI-00054T-8o for qemu-devel@nongnu.org; Mon, 07 Nov 2016 17:45:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3sfH-0007vX-7m for qemu-devel@nongnu.org; Mon, 07 Nov 2016 17:45:20 -0500 References: <1478551093-32757-1-git-send-email-eblake@redhat.com> <943db5df-c9cd-ab0a-2964-0f78188937a1@redhat.com> From: Eric Blake Message-ID: <5e7c4a2a-d2d4-7174-471a-d0a5232d2023@redhat.com> Date: Mon, 7 Nov 2016 16:45:12 -0600 MIME-Version: 1.0 In-Reply-To: <943db5df-c9cd-ab0a-2964-0f78188937a1@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WAW72ioepnKhCeCxPo9iS2iOeP9foDNUS" Subject: Re: [Qemu-devel] [PATCH] nbd: Don't inf-loop on early EOF List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: qemu-block@nongnu.org, pbonzini@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WAW72ioepnKhCeCxPo9iS2iOeP9foDNUS From: Eric Blake To: Max Reitz , qemu-devel@nongnu.org Cc: qemu-block@nongnu.org, pbonzini@redhat.com Message-ID: <5e7c4a2a-d2d4-7174-471a-d0a5232d2023@redhat.com> Subject: Re: [PATCH] nbd: Don't inf-loop on early EOF References: <1478551093-32757-1-git-send-email-eblake@redhat.com> <943db5df-c9cd-ab0a-2964-0f78188937a1@redhat.com> In-Reply-To: <943db5df-c9cd-ab0a-2964-0f78188937a1@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/07/2016 04:22 PM, Max Reitz wrote: > On 07.11.2016 21:38, Eric Blake wrote: >> Commit 7d3123e converted a single read_sync() into a while loop >> that assumed that read_sync() would either make progress or give >> an error. But when the server hangs up early, the client sees >> EOF (a read_sync() of 0) and never makes progress, which in turn >> caused qemu-iotest './check -nbd 83' to go into an infinite loop. >> >> Rework the loop to accomodate reads cut short by EOF. >> >> Reported-by: Max Reitz >> Signed-off-by: Eric Blake >> --- >> nbd/client.c | 13 +++++++------ >> 1 file changed, 7 insertions(+), 6 deletions(-) >=20 > Reviewed-by: Max Reitz >=20 > But what about the server's nbd_negotiate_drop_sync()? It uses pretty > much the same code, so it seems susceptible to the same issue (only tha= t > we don't have a test for that side). If so, that's an older bug (pre-existing back to at least 2.6?), so it should be a separate fix, if anything. I guess it's time to figure out how to test the server against ill-behaved clients... --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --WAW72ioepnKhCeCxPo9iS2iOeP9foDNUS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJYIQP4AAoJEKeha0olJ0NqDsIH/jdv/frT6x8ZHdxbQdoDa0WT kZT3R8RVQpfbpKA7pz/yGfif+EPi9ym2FEbmlXcBwgEWZnAB4Ayoe4RU34vfvnZN PxMtaqbjXmr3hrXTU5PRjgC9hI5FCzvlOMXfMnbZf296TOdhZZFIi7N0jCr029bx /98b2nqvc4TyFTn3Syx9pYatPDbK6BjjIwyVcIVS5DdmESG4yGVtAtOpJLurCrRg 0hhTSmGMxjGZU+IwA7oNPTrKoWp8Fe6rSqBYAVSd6auAo63G9GtgVloKJr/0WUzN Ke/kc98zKq7nNuV11K0lz0dOxzJyveKHL9fgNdW3pZ6kMJ/gmjxk173xLjGutfM= =jrBv -----END PGP SIGNATURE----- --WAW72ioepnKhCeCxPo9iS2iOeP9foDNUS--