NBD dirty bitmap cleanups

The NBD spec, and even our code comment, says that if the client asks for NBD_OPT_LIST_META_CONTEXT with 0 queries, then we should reply with (a possibly-compressed representation of) ALL contexts that we are willing to let them try. But commit 3d068aff forgot to advertise qemu:dirty-bitmap:FOO.

Signed-off-by Eric Blake <[email protected]>

---
  nbd/server.c | 1 +
  1 file changed, 1 insertion(+)

nbd/server.c +1 -0

index dc04513de70..7af0ddffb20 100644
@@ -978,6 +978,7 @@ static int nbd_negotiate_meta_queries(NBDClient *client,
      if (client->opt == NBD_OPT_LIST_META_CONTEXT && !nb_queries) {
          /* enable all known contexts */
          meta->base_allocation = true;
+        meta->bitmap = !!meta->exp->export_bitmap;
      } else {
          for (i = 0; i < nb_queries; ++i) {
              ret = nbd_negotiate_meta_query(client, meta, errp);

The implementation of x-dirty-bitmap in qemu 3.0 silently falls back to treating the server as not supporting NBD_CMD_BLOCK_STATUS if a requested meta_context name was not negotiated, which in turn means treating the _entire_ image as data. Since our hack relied on using 'qemu-img map' to view which portions of the image were dirty by seeing what the redirected bdrv_block_status() treats as holes, this means that our fallback treats the entire image as clean. Better would have been to treat the entire image as dirty, or to fail to connect because the user's request for a specific context could not be honored. This patch goes with the latter.

Signed-off-by Eric Blake <[email protected]>

---
  block/nbd-client.c | 5 +++++
  1 file changed, 5 insertions(+)

block/nbd-client.c +5 -0

index 76e9ca3abeb..e6e27dafa6a 100644
@@ -992,6 +992,11 @@ int nbd_client_init(BlockDriverState *bs,
          logout("Failed to negotiate with the NBD server\n");
          return ret;
      }
+    if (x_dirty_bitmap && !client->info.base_allocation) {
+        error_setg(errp, "requested x-dirty-bitmap %s not found",
+                   x_dirty_bitmap);
+        return -EINVAL;
+    }
      if (client->info.flags & NBD_FLAG_READ_ONLY) {
          ret = bdrv_apply_auto_read_only(bs, "NBD export is read-only", errp);
          if (ret < 0) {

If nbd_client_init() fails after we are already connected, then the server will spam logs with:

Disconnect client, due to: Unexpected end-of-file before all bytes were read

unless we gracefully disconnect before closing the connection.

Ways to trigger this:

$ opts=driver=nbd,export=foo,server.type=inet,server.host=localhost,server.port=10809
$  qemu-img map --output=json --image-opts $opts,read-only=off
$  qemu-img map --output=json --image-opts $opts,x-dirty-bitmap=nosuch:

Signed-off-by Eric Blake <[email protected]>

---
  block/nbd-client.c | 18 ++++++++++++++++--
  1 file changed, 16 insertions(+), 2 deletions(-)

block/nbd-client.c +16 -2

index e6e27dafa6a..fc5b7eda8ee 100644
@@ -995,12 +995,13 @@ int nbd_client_init(BlockDriverState *bs,
      if (x_dirty_bitmap && !client->info.base_allocation) {
          error_setg(errp, "requested x-dirty-bitmap %s not found",
                     x_dirty_bitmap);
-        return -EINVAL;
+        ret = -EINVAL;
+        goto fail;
      }
      if (client->info.flags & NBD_FLAG_READ_ONLY) {
          ret = bdrv_apply_auto_read_only(bs, "NBD export is read-only", errp);
          if (ret < 0) {
-            return ret;
+            goto fail;
          }
      }
      if (client->info.flags & NBD_FLAG_SEND_FUA) {

@@ -1029,4 +1030,17 @@ int nbd_client_init(BlockDriverState *bs,
 
      logout("Established connection with NBD server\n");
      return 0;
+
+ fail:
+    /*
+     * We have connected, but must fail for other reasons. The
+     * connection is still blocking; send NBD_CMD_DISC as a courtesy
+     * to the server.
+     */
+    {
+        NBDRequest request = { .type = NBD_CMD_DISC };
+
+        nbd_send_request(client->ioc ?: QIO_CHANNEL(sioc), &request);
+        return ret;
+    }
  }

I'm working on a larger series for 4.0 that will add 'qemu-nbd --list' to show all possible information about a server's exports, to make it easier to diagnose if the right exports and bitmaps are present. But in the process, I found a few bugs that may be worth fixing in 3.1. By itself, this series does not warrant -rc4 (particularly since all of the problems exist in the 3.0 release, so this is not a regression fix), but if we have -rc4 for other reasons, these would make incremental backup support a bit more reliable.

Quoted 9 lines · Eric Blake

I'm working on a larger series for 4.0 that will add 'qemu-nbd --list' to show all possible information about a server's exports, to make it easier to diagnose if the right exports and bitmaps are present. But in the process, I found a few bugs that may be worth fixing in 3.1. By itself, this series does not warrant -rc4 (particularly since all of the problems exist in the 3.0 release, so this is not a regression fix), but if we have -rc4 for other reasons, these would make incremental backup support a bit more reliable.

And CVEs might be the reason for an -rc4. I'm queuing this on my NBD tree, ready to send a Pull Request by early Monday if we indeed end up with an -rc4.