From nobody Sun Oct 5 21:17:18 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.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 208.118.235.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 (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1544883126505903.6598841213548; Sat, 15 Dec 2018 06:12:06 -0800 (PST) Received: from localhost ([::1]:39231 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gYAfh-0002zC-Gp for importer@patchew.org; Sat, 15 Dec 2018 09:12:01 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gYAOy-0005WH-67 for qemu-devel@nongnu.org; Sat, 15 Dec 2018 08:54:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gYAOx-0000Ou-2B for qemu-devel@nongnu.org; Sat, 15 Dec 2018 08:54:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35978) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gYAOu-0000MI-Bk; Sat, 15 Dec 2018 08:54:40 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B300380F6C; Sat, 15 Dec 2018 13:54:39 +0000 (UTC) Received: from red.redhat.com (ovpn-122-76.rdu2.redhat.com [10.10.122.76]) by smtp.corp.redhat.com (Postfix) with ESMTP id 96E085C1B2; Sat, 15 Dec 2018 13:54:38 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Sat, 15 Dec 2018 07:53:23 -0600 Message-Id: <20181215135324.152629-22-eblake@redhat.com> In-Reply-To: <20181215135324.152629-1-eblake@redhat.com> References: <20181215135324.152629-1-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Sat, 15 Dec 2018 13:54:39 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2 21/22] nbd/client: Work around 3.0 bug for listing meta contexts 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: nsoffer@redhat.com, vsementsov@virtuozzo.com, jsnow@redhat.com, rjones@redhat.com, qemu-block@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Commit 3d068aff forgot to advertise available qemu: contexts when the client requests a list with 0 queries. Furthermore, 3.0 shipped with a qemu-img hack of x-dirty-bitmap (commit 216ee365) that _silently_ acts as though the entire image is clean if a requested bitmap is not present. Both bugs have been recently fixed to give full output from the start, and to refuse a connection if a requested x-dirty-bitmap was not found. Still, it is likely that there will be users that have to work with a mix of old and new qemu versions, depending on which features get backported where, at which point being able to rely on 'qemu-img --list' output to know for sure whether a given NBD export has the desired dirty bitmap is much nicer than blindly connecting and risking that the entire image may appear clean. We can make our --list code smart enough to work around buggy servers by tracking whether we've seen any qemu: replies in the original 0-query list; if not, recurse to a single query on "qemu:" (which may still have no replies, but then we know for sure we didn't trip up on the server bug). Signed-off-by: Eric Blake --- Done as a separate patch to make it easier to revert when we no longer care about 3.0 servers v2: rebase on top of earlier patch splits --- nbd/client.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/nbd/client.c b/nbd/client.c index d392b5e8bee..48fa6e10b92 100644 --- a/nbd/client.c +++ b/nbd/client.c @@ -21,6 +21,7 @@ #include "qapi/error.h" #include "trace.h" #include "nbd-internal.h" +#include "qemu/cutils.h" /* Definitions for opaque data types */ @@ -819,6 +820,8 @@ static int nbd_list_meta_contexts(QIOChannel *ioc, Error **errp) { int ret; + int seen_any =3D false; + int seen_qemu =3D false; if (nbd_send_one_meta_context(ioc, NBD_OPT_LIST_META_CONTEXT, info->name, NULL, errp) < 0) { @@ -830,9 +833,25 @@ static int nbd_list_meta_contexts(QIOChannel *ioc, ret =3D nbd_receive_one_meta_context(ioc, NBD_OPT_LIST_META_CONTEX= T, &context, NULL, errp); + if (ret =3D=3D 0 && seen_any && !seen_qemu) { + /* + * Work around qemu 3.0 bug: the server forgot to send + * "qemu:" replies to 0 queries. If we saw at least one + * reply (probably base:allocation), but none of them were + * qemu:, then run a more specific query to make sure. + */ + seen_qemu =3D true; + if (nbd_send_one_meta_context(ioc, NBD_OPT_LIST_META_CONTEXT, + info->name, "qemu:", errp) < 0) { + return -1; + } + continue; + } if (ret <=3D 0) { return ret; } + seen_any =3D true; + seen_qemu |=3D strstart(context, "qemu:", NULL); info->contexts =3D g_renew(char *, info->contexts, ++info->n_conte= xts); info->contexts[info->n_contexts - 1] =3D context; } --=20 2.17.2