From nobody Sun Feb 8 16:17:49 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (209.51.188.17 [209.51.188.17]) by mx.zohomail.com with SMTPS id 1553351184282806.5846421589838; Sat, 23 Mar 2019 07:26:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:43990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7hb9-0007Sx-CG for importer@patchew.org; Sat, 23 Mar 2019 10:26:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7ha6-00072m-Ad for qemu-devel@nongnu.org; Sat, 23 Mar 2019 10:25:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h7ha5-0005gv-As for qemu-devel@nongnu.org; Sat, 23 Mar 2019 10:25:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47084) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h7ha3-0005fq-1S; Sat, 23 Mar 2019 10:25:03 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9363E3082B22; Sat, 23 Mar 2019 14:25:01 +0000 (UTC) Received: from blue.redhat.com (ovpn-116-65.phx2.redhat.com [10.3.116.65]) by smtp.corp.redhat.com (Postfix) with ESMTP id CB1B710018FB; Sat, 23 Mar 2019 14:24:58 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Sat, 23 Mar 2019 09:24:55 -0500 Message-Id: <20190323142455.5301-1-eblake@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Sat, 23 Mar 2019 14:25:01 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH for-4.0] nbd: Permit simple error to NBD_CMD_BLOCK_STATUS X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , vsementsov@virtuozzo.com, qemu-block@nongnu.org, rjones@redhat.com, Max Reitz , jsnow@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" The NBD spec is clear that when structured replies are active, a simple error reply is acceptable to any command except for NBD_CMD_READ. However, we were mistakenly requiring structured errors for NBD_CMD_BLOCK_STATUS, and hanging up on a server that gave a simple error (since qemu does not behave as such a server, we didn't notice the problem until now). Broken since its introduction in commit 78a33ab5 (v2.12). Howeve, even if we had gotten it correct to accept simple errors back then, we run into another problem: the client treats the server's reply as fatal and hangs up on the connection, instead of merely failing the block status request but being ready for the next command. Broken in commit 7f86068d (unreleased). Signed-off-by: Eric Blake --- I confirmed that when backporting things for qemu 2.12 through 3.1, the first hunk is sufficient to let clients tolerate a simple error without hanging up (the second hunk is only required for the 4.0 code base). Rich - if you choose to make nbdkit work around the qemu 2.12 bug where it refuses to communicate with a server that supports NBD_OPT_SET_META_CONTEXT but not base:allocation, you'll also want to make sure that you send a structured error instead of a simple error to any failures of NBD_CMD_BLOCK_STATUS. block/nbd-client.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/block/nbd-client.c b/block/nbd-client.c index bfbaf7ebe94..5fc9ea40383 100644 --- a/block/nbd-client.c +++ b/block/nbd-client.c @@ -718,9 +718,7 @@ static int nbd_co_receive_blockstatus_reply(NBDClientSe= ssion *s, bool received =3D false; assert(!extent->length); - NBD_FOREACH_REPLY_CHUNK(s, iter, handle, s->info.structured_reply, - NULL, &reply, &payload) - { + NBD_FOREACH_REPLY_CHUNK(s, iter, handle, false, NULL, &reply, &payload= ) { int ret; NBDStructuredReplyChunk *chunk =3D &reply.structured; @@ -758,9 +756,11 @@ static int nbd_co_receive_blockstatus_reply(NBDClientS= ession *s, payload =3D NULL; } - if (!extent->length && !iter.err) { - error_setg(&iter.err, - "Server did not reply with any status extents"); + if (!extent->length && !iter.request_ret) { + if (!iter.err) { + error_setg(&iter.err, + "Server did not reply with any status extents"); + } if (!iter.ret) { iter.ret =3D -EIO; } --=20 2.20.1