qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v12 03/17] block: Introduce bdrv_dirty_bitmap_gr


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH v12 03/17] block: Introduce bdrv_dirty_bitmap_granularity()
Date: Tue, 10 Feb 2015 17:03:24 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 2015-02-09 at 20:35, John Snow wrote:
This returns the granularity (in bytes) of dirty bitmap,
which matches the QMP interface and the existing query
interface.

Small adjustments are made to ensure that granularity-- in bytes--

I guess these should be ASCII replacements of an em dash? But they kind of look like decrement operators to me...

is handled consistently as a uint64_t throughout the code.

Signed-off-by: John Snow <address@hidden>
---
  block.c               | 17 +++++++++++------
  include/block/block.h |  3 ++-
  2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/block.c b/block.c
index 1661ff9..83f411f 100644
--- a/block.c
+++ b/block.c
@@ -5387,12 +5387,13 @@ void bdrv_dirty_bitmap_make_anon(BlockDriverState *bs, 
BdrvDirtyBitmap *bitmap)
  }
BdrvDirtyBitmap *bdrv_create_dirty_bitmap(BlockDriverState *bs,
-                                          int granularity,
+                                          uint64_t granularity,
                                            const char *name,
                                            Error **errp)
  {
      int64_t bitmap_size;
      BdrvDirtyBitmap *bitmap;
+    int sector_granularity;
assert((granularity & (granularity - 1)) == 0); @@ -5400,8 +5401,8 @@ BdrvDirtyBitmap *bdrv_create_dirty_bitmap(BlockDriverState *bs,
          error_setg(errp, "Bitmap already exists: %s", name);
          return NULL;
      }
-    granularity >>= BDRV_SECTOR_BITS;
-    assert(granularity);
+    sector_granularity = granularity >> BDRV_SECTOR_BITS;

I can see Coverity's screams regarding a possible overflow already... (but maybe it doesn't even scream and I'm just overcautious)

Whether you add an assert((granularity >> BDRV_SECTOR_BITS) <= INT_MAX) or not here (it does look pretty ugly and it is pretty unnecessary, I know) or not, and whether you do something about the decrement operators in the commit message or not:

Reviewed-by: Max Reitz <address@hidden>



reply via email to

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