qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 06/10] block: add delayed bitmap successor cl


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v5 06/10] block: add delayed bitmap successor cleanup
Date: Fri, 5 Jun 2015 13:56:10 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, Jun 04, 2015 at 05:46:08PM -0400, John Snow wrote:
> @@ -3190,19 +3193,13 @@ BdrvDirtyBitmap 
> *bdrv_dirty_bitmap_abdicate(BlockDriverState *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 *parent)
>  {
>      BdrvDirtyBitmap *successor = parent->successor;
>  
> -    if (!successor) {
> -        error_setg(errp, "Cannot reclaim a successor when none is present");
> -        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.

Attachment: pgpb3_nWhXNeM.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]