All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Richard W . M . Jones" <rjones@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>,
	"open list:Network Block Dev..." <qemu-block@nongnu.org>
Subject: [Qemu-devel] [PULL 02/14] nbd: Tolerate some server non-compliance in NBD_CMD_BLOCK_STATUS
Date: Mon,  1 Apr 2019 09:08:51 -0500	[thread overview]
Message-ID: <20190401140903.19186-3-eblake@redhat.com> (raw)
In-Reply-To: <20190401140903.19186-1-eblake@redhat.com>

The NBD spec states that NBD_CMD_FLAG_REQ_ONE (which we currently
always use) should not reply with an extent larger than our request,
and that the server's response should be exactly one extent. Right
now, that means that if a server sends more than one extent, we treat
the server as broken, fail the block status request, and disconnect,
which prevents all further use of the block device. But while good
software should be strict in what it sends, it should be tolerant in
what it receives.

While trying to implement NBD_CMD_BLOCK_STATUS in nbdkit, we
temporarily had a non-compliant server sending too many extents in
spite of REQ_ONE. Oddly enough, 'qemu-img convert' with qemu 3.1
failed with a somewhat useful message:
  qemu-img: Protocol error: invalid payload for NBD_REPLY_TYPE_BLOCK_STATUS

which then disappeared with commit d8b4bad8, on the grounds that an
error message flagged only at the time of coroutine teardown is
pointless, and instead we should rely on the actual failed API to
report an error - in other words, the 3.1 behavior was masking the
fact that qemu-img was not reporting an error. That has since been
fixed in the previous patch, where qemu-img convert now fails with:
  qemu-img: error while reading block status of sector 0: Invalid argument

But even that is harsh.  Since we already partially relaxed things in
commit acfd8f7a to tolerate a server that exceeds the cap (although
that change was made prior to the NBD spec actually putting a cap on
the extent length during REQ_ONE - in fact, the NBD spec change was
BECAUSE of the qemu behavior prior to that commit), it's not that much
harder to argue that we should also tolerate a server that sends too
many extents.  But at the same time, it's nice to trace when we are
being tolerant of server non-compliance, in order to help server
writers fix their implementations to be more portable (if they refer
to our traces, rather than just stderr).

Reported-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20190323212639.579-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
 block/nbd-client.c | 21 ++++++++++++++++-----
 block/trace-events |  1 +
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/block/nbd-client.c b/block/nbd-client.c
index bfbaf7ebe94..8fe660b6093 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -240,8 +240,8 @@ static int nbd_parse_offset_hole_payload(NBDStructuredReplyChunk *chunk,
 }

 /* nbd_parse_blockstatus_payload
- * support only one extent in reply and only for
- * base:allocation context
+ * Based on our request, we expect only one extent in reply, for the
+ * base:allocation context.
  */
 static int nbd_parse_blockstatus_payload(NBDClientSession *client,
                                          NBDStructuredReplyChunk *chunk,
@@ -250,7 +250,8 @@ static int nbd_parse_blockstatus_payload(NBDClientSession *client,
 {
     uint32_t context_id;

-    if (chunk->length != sizeof(context_id) + sizeof(*extent)) {
+    /* The server succeeded, so it must have sent [at least] one extent */
+    if (chunk->length < sizeof(context_id) + sizeof(*extent)) {
         error_setg(errp, "Protocol error: invalid payload for "
                          "NBD_REPLY_TYPE_BLOCK_STATUS");
         return -EINVAL;
@@ -276,10 +277,20 @@ static int nbd_parse_blockstatus_payload(NBDClientSession *client,
         return -EINVAL;
     }

-    /* The server is allowed to send us extra information on the final
-     * extent; just clamp it to the length we requested. */
+    /*
+     * We used NBD_CMD_FLAG_REQ_ONE, so the server should not have
+     * sent us any more than one extent, nor should it have included
+     * status beyond our request in that extent. However, it's easy
+     * enough to ignore the server's noncompliance without killing the
+     * connection; just ignore trailing extents, and clamp things to
+     * the length of our request.
+     */
+    if (chunk->length > sizeof(context_id) + sizeof(*extent)) {
+        trace_nbd_parse_blockstatus_compliance("more than one extent");
+    }
     if (extent->length > orig_length) {
         extent->length = orig_length;
+        trace_nbd_parse_blockstatus_compliance("extent length too large");
     }

     return 0;
diff --git a/block/trace-events b/block/trace-events
index e6bb5a8f05c..debb25c0ac8 100644
--- a/block/trace-events
+++ b/block/trace-events
@@ -157,6 +157,7 @@ nvme_cmd_map_qiov_iov(void *s, int i, void *page, int pages) "s %p iov[%d] %p pa
 iscsi_xcopy(void *src_lun, uint64_t src_off, void *dst_lun, uint64_t dst_off, uint64_t bytes, int ret) "src_lun %p offset %"PRIu64" dst_lun %p offset %"PRIu64" bytes %"PRIu64" ret %d"

 # nbd-client.c
+nbd_parse_blockstatus_compliance(const char *err) "ignoring extra data from non-compliant server: %s"
 nbd_read_reply_entry_fail(int ret, const char *err) "ret = %d, err: %s"
 nbd_co_request_fail(uint64_t from, uint32_t len, uint64_t handle, uint16_t flags, uint16_t type, const char *name, int ret, const char *err) "Request failed { .from = %" PRIu64", .len = %" PRIu32 ", .handle = %" PRIu64 ", .flags = 0x%" PRIx16 ", .type = %" PRIu16 " (%s) } ret = %d, err: %s"

-- 
2.20.1

  parent reply	other threads:[~2019-04-01 14:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01 14:08 [Qemu-devel] [PULL 00/14] NBD patches for 4.0-rc2 Eric Blake
2019-04-01 14:08 ` [Qemu-devel] [PULL 01/14] qemu-img: Report bdrv_block_status failures Eric Blake
2019-04-01 14:08 ` Eric Blake [this message]
2019-04-01 14:08 ` [Qemu-devel] [PULL 03/14] nbd: Don't lose server's error to NBD_CMD_BLOCK_STATUS Eric Blake
2019-04-01 14:08 ` [Qemu-devel] [PULL 04/14] nbd: Permit simple " Eric Blake
2019-04-01 14:08 ` [Qemu-devel] [PULL 05/14] qemu-img: Gracefully shutdown when map can't finish Eric Blake
2019-04-01 14:08 ` [Qemu-devel] [PULL 06/14] nbd-client: Work around server BLOCK_STATUS misalignment at EOF Eric Blake
2019-04-01 14:08 ` [Qemu-devel] [PULL 07/14] iotests: Add 241 to test NBD on unaligned images Eric Blake
2019-04-10 17:45   ` [Qemu-devel] [Qemu-block] " Max Reitz
2019-04-10 18:01     ` Eric Blake
2019-04-01 14:08 ` [Qemu-devel] [PULL 08/14] nbd/client: Lower min_block for block-status, unaligned size Eric Blake
2019-04-01 14:08 ` [Qemu-devel] [PULL 09/14] nbd/client: Report offsets in bdrv_block_status Eric Blake
2019-04-01 14:08 ` [Qemu-devel] [PULL 10/14] nbd/client: Reject inaccessible tail of inconsistent server Eric Blake
2019-04-02 22:40   ` Eric Blake
2019-04-01 14:09 ` [Qemu-devel] [PULL 11/14] nbd/client: Support qemu-img convert from unaligned size Eric Blake
2019-04-01 14:09 ` [Qemu-devel] [PULL 12/14] block: Add bdrv_get_request_alignment() Eric Blake
2019-04-01 14:09 ` [Qemu-devel] [PULL 13/14] nbd/server: Advertise actual minimum block size Eric Blake
2019-04-01 14:09 ` [Qemu-devel] [PULL 14/14] nbd/client: Trace server noncompliance on structured reads Eric Blake
2019-04-02  5:29 ` [Qemu-devel] [PULL 00/14] NBD patches for 4.0-rc2 Peter Maydell

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=20190401140903.19186-3-eblake@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=vsementsov@virtuozzo.com \
    /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.