From nobody Mon Feb 9 14:34:11 2026 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 (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1523882436159863.7434316713878; Mon, 16 Apr 2018 05:40:36 -0700 (PDT) Received: from localhost ([::1]:43492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f83Qe-00011G-4V for importer@patchew.org; Mon, 16 Apr 2018 08:40:16 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f83P5-00009h-Tm for qemu-devel@nongnu.org; Mon, 16 Apr 2018 08:38:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f83P4-0008JN-Tj for qemu-devel@nongnu.org; Mon, 16 Apr 2018 08:38:39 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:39010 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f83Oy-0008Fs-LM; Mon, 16 Apr 2018 08:38:32 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AF5FF722FE; Mon, 16 Apr 2018 12:38:31 +0000 (UTC) Received: from localhost (unknown [10.40.205.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79176215CDC8; Mon, 16 Apr 2018 12:38:30 +0000 (UTC) From: Max Reitz To: qemu-block@nongnu.org Date: Mon, 16 Apr 2018 14:38:21 +0200 Message-Id: <20180416123822.11744-2-mreitz@redhat.com> In-Reply-To: <20180416123822.11744-1-mreitz@redhat.com> References: <20180416123822.11744-1-mreitz@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 16 Apr 2018 12:38:31 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 16 Apr 2018 12:38:31 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mreitz@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PULL 1/2] qcow2: try load bitmaps only once 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 , Peter Maydell , qemu-devel@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Vladimir Sementsov-Ogievskiy Checking reopen by existence of some bitmaps is wrong, as it may be some other bitmaps, or on the other hand, user may remove bitmaps. This criteria is bad. To simplify things and make behavior more predictable let's just add a flag to remember, that we've already tried to load bitmaps on open and do not want do it again. Signed-off-by: Vladimir Sementsov-Ogievskiy Message-id: 20180411122606.367301-2-vsementsov@virtuozzo.com [mreitz: Changed comment wording according to Eric Blake's suggestion] Signed-off-by: Max Reitz --- block/qcow2.h | 1 + block/qcow2.c | 16 ++++++++-------- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/block/qcow2.h b/block/qcow2.h index d301f77cea..adf5c3950f 100644 --- a/block/qcow2.h +++ b/block/qcow2.h @@ -298,6 +298,7 @@ typedef struct BDRVQcow2State { uint32_t nb_bitmaps; uint64_t bitmap_directory_size; uint64_t bitmap_directory_offset; + bool dirty_bitmaps_loaded; =20 int flags; int qcow_version; diff --git a/block/qcow2.c b/block/qcow2.c index 486f3e83b7..ef68772aca 100644 --- a/block/qcow2.c +++ b/block/qcow2.c @@ -1142,6 +1142,7 @@ static int coroutine_fn qcow2_do_open(BlockDriverStat= e *bs, QDict *options, uint64_t ext_end; uint64_t l1_vm_state_index; bool update_header =3D false; + bool header_updated =3D false; =20 ret =3D bdrv_pread(bs->file, 0, &header, sizeof(header)); if (ret < 0) { @@ -1480,10 +1481,9 @@ static int coroutine_fn qcow2_do_open(BlockDriverSta= te *bs, QDict *options, s->autoclear_features &=3D QCOW2_AUTOCLEAR_MASK; } =20 - if (bdrv_dirty_bitmap_next(bs, NULL)) { - /* It's some kind of reopen with already existing dirty bitmaps. T= here - * are no known cases where we need loading bitmaps in such situat= ion, - * so it's safer don't load them. + if (s->dirty_bitmaps_loaded) { + /* It's some kind of reopen. There are no known cases where we nee= d to + * reload bitmaps in such a situation, so it's safer to skip them. * * Moreover, if we have some readonly bitmaps and we are reopening= for * rw we should reopen bitmaps correspondingly. @@ -1491,13 +1491,13 @@ static int coroutine_fn qcow2_do_open(BlockDriverSt= ate *bs, QDict *options, if (bdrv_has_readonly_bitmaps(bs) && !bdrv_is_read_only(bs) && !(bdrv_get_flags(bs) & BDRV_O_INACTI= VE)) { - bool header_updated =3D false; qcow2_reopen_bitmaps_rw_hint(bs, &header_updated, &local_err); - update_header =3D update_header && !header_updated; } - } else if (qcow2_load_dirty_bitmaps(bs, &local_err)) { - update_header =3D false; + } else { + header_updated =3D qcow2_load_dirty_bitmaps(bs, &local_err); + s->dirty_bitmaps_loaded =3D true; } + update_header =3D update_header && !header_updated; if (local_err !=3D NULL) { error_propagate(errp, local_err); ret =3D -EINVAL; --=20 2.14.3