From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0rAX-0002kA-LY for qemu-devel@nongnu.org; Fri, 05 Jun 2015 08:56:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z0rAW-0008QG-Px for qemu-devel@nongnu.org; Fri, 05 Jun 2015 08:56:17 -0400 Date: Fri, 5 Jun 2015 13:56:10 +0100 From: Stefan Hajnoczi Message-ID: <20150605125610.GH23825@stefanha-thinkpad.redhat.com> References: <1433454372-16356-1-git-send-email-jsnow@redhat.com> <1433454372-16356-7-git-send-email-jsnow@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbfcI4OLZ4XW0yH2" Content-Disposition: inline In-Reply-To: <1433454372-16356-7-git-send-email-jsnow@redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 06/10] block: add delayed bitmap successor cleanup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: kwolf@redhat.com, famz@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com, vsementsov@parallels.com --VbfcI4OLZ4XW0yH2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 04, 2015 at 05:46:08PM -0400, John Snow wrote: > @@ -3190,19 +3193,13 @@ BdrvDirtyBitmap *bdrv_dirty_bitmap_abdicate(Block= DriverState *bs, > * we may wish to re-join the parent and child/successor. > * The merged parent will be un-frozen, but not explicitly re-enabled. > */ > -BdrvDirtyBitmap *bdrv_reclaim_dirty_bitmap(BlockDriverState *bs, > - BdrvDirtyBitmap *parent, > - Error **errp) > +static BdrvDirtyBitmap *bdrv_reclaim_dirty_bitmap(BlockDriverState *bs, > + BdrvDirtyBitmap *paren= t) > { > BdrvDirtyBitmap *successor =3D parent->successor; > =20 > - if (!successor) { > - error_setg(errp, "Cannot reclaim a successor when none is presen= t"); > - return NULL; > - } > - > + assert(successor); > if (!hbitmap_merge(parent->bitmap, successor->bitmap)) { > - error_setg(errp, "Merging of parent and successor bitmap failed"= ); > return NULL; > } Is this reachable? If the bitmap size and granularity match then hbitmap_merge() does not fail. This should probably be covered with an assertion instead to show that this is not allowed to happen. --VbfcI4OLZ4XW0yH2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVcZxqAAoJEJykq7OBq3PIi24H/3JDw3tGWUnSIyTd+2c8QDaU K1x3+gAsAgE5Qul+8IJ4p3jhtrw7RJn9hH2BQHR8L+wERlExkCUre1212z8IChX3 gpFzBVT09j8cb0bss4AnU74PqqQCwkgS01UaEx2jKtWmTd853hModh28+Efa4QMr hpT6QWilbLgHEjJoRCMfz42CREhJzeAYpWZokLfm48YzLSJ8G3Oh1jRixBK51H1q f7KvJA3e0YHsip1ybPqvWfBCWs1SzIG54Hjla2uxBmC7uW0a8gYK8WkYS2Ha0vUy Lm4dKvXP5/OLVlXb2Zt2brz0K9H5brYn03nvAiqlo1IvkN9mvIswgigE0L/VKLY= =TxwT -----END PGP SIGNATURE----- --VbfcI4OLZ4XW0yH2--