All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Bligh <alex@alex.org.uk>
To: Eric Blake <eblake@redhat.com>
Cc: Alex Bligh <alex@alex.org.uk>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	qemu-block@nongnu.org,
	"nbd-general@lists.sourceforge.net"
	<nbd-general@lists.sourceforge.net>
Subject: Re: [Qemu-devel] [PATCH v4 04/11] nbd: Improve server handling of bogus commands
Date: Mon, 13 Jun 2016 22:41:05 +0100	[thread overview]
Message-ID: <6DD06745-C91C-4BFB-BFE5-92E5982ACB42@alex.org.uk> (raw)
In-Reply-To: <575EA656.80508@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]


On 13 Jun 2016, at 13:25, Eric Blake <eblake@redhat.com> 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





[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

  reply	other threads:[~2016-06-13 21:41 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11 22:39 [Qemu-devel] [PATCH v4 00/11] nbd: tighter protocol compliance Eric Blake
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 01/11] nbd: Use BDRV_REQ_FUA for better FUA where supported Eric Blake
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 02/11] nbd: More debug typo fixes, use correct formats Eric Blake
2016-06-13 12:04   ` Paolo Bonzini
2016-06-13 12:21     ` Eric Blake
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 03/11] nbd: Quit server after any write error Eric Blake
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 04/11] nbd: Improve server handling of bogus commands Eric Blake
2016-06-13 12:10   ` Paolo Bonzini
2016-06-13 12:25     ` Eric Blake
2016-06-13 21:41       ` Alex Bligh [this message]
2016-06-14 13:32         ` Paolo Bonzini
2016-06-14 15:02           ` Alex Bligh
2016-06-14 15:11             ` Paolo Bonzini
2016-06-14 15:59               ` Alex Bligh
2016-06-14 22:05                 ` Paolo Bonzini
2016-06-15  7:05             ` [Qemu-devel] [Nbd] " Wouter Verhelst
2016-06-15  8:03               ` Wouter Verhelst
2016-06-15  8:52                 ` Alex Bligh
2016-06-15  9:18                   ` Paolo Bonzini
2016-06-15 10:27                     ` Alex Bligh
2016-06-15 10:34                       ` Paolo Bonzini
2016-06-15 12:13                       ` Wouter Verhelst
2016-06-15  7:02         ` Wouter Verhelst
2016-06-13 12:19   ` [Qemu-devel] " Paolo Bonzini
2016-06-13 16:54     ` Eric Blake
2016-06-14 18:24     ` Eric Blake
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 05/11] nbd: Reject unknown request flags Eric Blake
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 06/11] nbd: Group all Linux-specific ioctl code in one place Eric Blake
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 07/11] nbd: Clean up ioctl handling of qemu-nbd -c Eric Blake
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 08/11] nbd: Limit nbdflags to 16 bits Eric Blake
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 09/11] nbd: Add qemu-nbd -D for human-readable description Eric Blake
2016-05-12  7:47   ` Daniel P. Berrange
2016-05-12 15:38     ` Eric Blake
2016-05-12 15:51       ` Daniel P. Berrange
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 10/11] nbd: Detect servers that send unexpected error values Eric Blake
2016-05-11 22:39 ` [Qemu-devel] [PATCH v4 11/11] nbd: Avoid magic number for NBD max name size Eric Blake
2016-05-12 16:04 ` [Qemu-devel] [PATCH v4 00/11] nbd: tighter protocol compliance Alex Bligh
2016-06-01 23:02 ` Eric Blake
2016-06-13 16:28 ` Paolo Bonzini
2016-06-13 16:49   ` Eric Blake
2016-06-14 16:31     ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6DD06745-C91C-4BFB-BFE5-92E5982ACB42@alex.org.uk \
    --to=alex@alex.org.uk \
    --cc=eblake@redhat.com \
    --cc=nbd-general@lists.sourceforge.net \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.