qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [RFC PATCH 03/16] block: Allow .bdrv_close


From: John Snow
Subject: Re: [Qemu-block] [Qemu-devel] [RFC PATCH 03/16] block: Allow .bdrv_close callback to release dirty bitmaps
Date: Mon, 8 Feb 2016 19:23:33 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0


On 01/26/2016 05:38 AM, Fam Zheng wrote:
> If the driver owns some dirty bitmaps, this assertion will fail.
> 
> The correct place to release them is in bdrv_close, so move the
> assertion one line down.
> 
> Signed-off-by: Fam Zheng <address@hidden>
> ---
>  block.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/block.c b/block.c
> index afb71c0..fa6ad1d 100644
> --- a/block.c
> +++ b/block.c
> @@ -2348,10 +2348,11 @@ static void bdrv_delete(BlockDriverState *bs)
>      assert(!bs->job);
>      assert(bdrv_op_blocker_is_empty(bs));
>      assert(!bs->refcnt);
> -    assert(QLIST_EMPTY(&bs->dirty_bitmaps));
>  
>      bdrv_close(bs);
>  
> +    assert(QLIST_EMPTY(&bs->dirty_bitmaps));
> +
>      /* remove from list, if necessary */
>      bdrv_make_anon(bs);
>  
> 

I think now is where we need to begin distinguishing internally owned
bitmaps from qmp/monitor created ones. I suppose this is just an assert
so it isn't changing much, but there are different ideas at play here...

- Bitmaps created internally for various reasons (backups, migration, etc)
- Bitmaps created explicitly by the user (transient bitmaps)
- Bitmaps autoloaded from qcow2, qbm, etc (persistent bitmaps)

We should still make sure we don't have any of the first two types when
we go to close the bitmap, and making sure we have none of the third is
reasonable after the close.



reply via email to

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