From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCZbg-0005Dc-2J for qemu-devel@nongnu.org; Mon, 13 Jun 2016 17:41:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCZbe-0000tm-QI for qemu-devel@nongnu.org; Mon, 13 Jun 2016 17:41:16 -0400 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_68D76758-70B3-4032-99A0-1942AE910BA3"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Alex Bligh In-Reply-To: <575EA656.80508@redhat.com> Date: Mon, 13 Jun 2016 22:41:05 +0100 Message-Id: <6DD06745-C91C-4BFB-BFE5-92E5982ACB42@alex.org.uk> References: <1463006384-7734-1-git-send-email-eblake@redhat.com> <1463006384-7734-5-git-send-email-eblake@redhat.com> <852e526a-5235-499a-741e-a695f5e74f83@redhat.com> <575EA656.80508@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 04/11] nbd: Improve server handling of bogus commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Alex Bligh , Paolo Bonzini , "qemu-devel@nongnu.org" , qemu-block@nongnu.org, "nbd-general@lists.sourceforge.net" --Apple-Mail=_68D76758-70B3-4032-99A0-1942AE910BA3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 13 Jun 2016, at 13:25, Eric Blake wrote: > On 06/13/2016 06:10 AM, Paolo Bonzini wrote: >> >> >> On 12/05/2016 00:39, Eric Blake wrote: >>> - If we report an error to NBD_CMD_READ, we are not writing out >>> any data payload; but the protocol says that a client can expect >>> to read the payload no matter what (and must instead ignore it), >>> which means the client will start reading our next replies as >>> its data payload. Fix by disconnecting (an alternative fix of >>> sending bogus payload would be trickier to implement). >> >> This is an error in the spec. The Linux driver doesn't expect to read >> the payload here, and neither does block/nbd-client.c. > > That's one of the reasons that there is a proposal to add > STRUCTURED_READ to the spec (although I still haven't had time to > implement that for qemu), so that we have a newer approach that allows > for proper error handling without ambiguity on whether bogus bytes must > be sent on a failed read. But you'd have to convince me that ALL > existing NBD server and client implementations expect to handle a read > error without read payload, otherwise, I will stick with the notion that > the current spec wording is correct, and that read errors CANNOT be > gracefully recovered from unless BOTH sides transfer (possibly bogus) > bytes along with the error message, and which is why BOTH sides of the > protocol are warned that read errors usually result in a disconnection > rather than clean continuation, without the addition of STRUCTURED_READ. To back up what Eric said: Unfortunately the design is pretty much broken for reporting errors on reads (at least in part as there is no way to signal errors that occur after some of the reply has been written). The spec specifies that on a read, no matter whether or not there is an error, the data is all sent. This was after some mailing list conversations on the subject which indicated this was the least broken way to do things (IIRC). This is actually what nbd-server.c does in the threaded handler: https://github.com/yoe/nbd/blob/master/nbd-server.c#L1468 For amusement value, the non-threaded handler (which is not used any more) does not send any payload on an error: https://github.com/yoe/nbd/blob/master/nbd-server.c#L1734 In essence read error handling is a horrible mess in NBD, and I would not expect it to work in general :-( -- Alex Bligh --Apple-Mail=_68D76758-70B3-4032-99A0-1942AE910BA3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXXyhxAAoJEBPm5K7i9iORZtYP/iVVNUTUH+MnzyFTQly3nqsP cmaApvsDGX+o0VoKxCeKANjkchG6PJKWUrWtflz1kGg0S3D0IK/x3PUWbyDl6O/K mRD5FA3f6XXyWVyQN8fl2NDYGQbrErQdpPVD4gzhXB3sxvXVe6oH3KhPjGZ/7jGI uyTMojxM8vaYbkQzbU/+tSsIqk0PZl3yOADmPuJGOdFCgQoE7baPDzhRkI6iviKu ADFAai4tbUzzZRhAXx84IjLk0nHah9YmtICx12Ewm9iQkeCopPtP8c1DDp7KpzVP 7qOAosU6Rlq+Y75QBTk+LSAE76l5F8K5XOkYWfewSBENjidvZ7hAd2jii9HtpdUy 5ZdvMDd3nxOxU2DiDF5EHBkRamy08Noa0lRX1/h1gVr+wMVYiB76OX7nquuBSgAJ L7tFjKaasTgJkulWgNaOAiQ/XahV4UDjuI6rwXW9+Tw/xXa3Cxz040HkSy+NCkpA v0zMfPZ4rF43emOkfnk/+z307DNYU81UtsK6kU1lv2cLheIBMY63JiCqYeZsjFhw MIex7yI2Oys8VZKKSkR/iFYhzHqLbCwz3JatUZxibJWI7f4k7pa6EZ2wz42djJoG 0E47W2Iwsuf3ZoHEoTzBBVVC+x1TrZyAmDHWU2k0hD50nlCI1WzpEreLLANt2PZo 2Pnp0vXeE+DhlmRzCGpO =UieT -----END PGP SIGNATURE----- --Apple-Mail=_68D76758-70B3-4032-99A0-1942AE910BA3--