qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: John Snow <jsnow@redhat.com>, qemu-devel@nongnu.org
Cc: vsementsov@virtuozzo.com, Kevin Wolf <kwolf@redhat.com>,
	qemu-block@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/5] block/qcow2-bitmap: Skip length check in some cases
Date: Wed, 6 Mar 2019 06:34:24 -0600	[thread overview]
Message-ID: <dfc7c39d-78df-b576-6e24-96846bb31193@redhat.com> (raw)
In-Reply-To: <20190305234337.18353-2-jsnow@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

On 3/5/19 5:43 PM, John Snow wrote:
> If we were to allow resizes, the length check that happens when we load
> bitmap headers from disk when we read or store bitmaps would begin to
> fail:
> 
> Imagine the circumstance where we've resized bitmaps in memory, but they still
> have the old values on-disk. The lengths will no longer match bdrv_getlength,
> so we must allow this check to be skipped when flushing bitmaps to disk.
> 
> Limit this to when we are about to overwrite the headers: we will verify the
> outgoing headers, but we will skip verifying the known stale headers.

No-op until we actually do allow resizes later in the series, but makes
sense.

> 
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
>  block/qcow2-bitmap.c | 34 +++++++++++++++++++++-------------
>  1 file changed, 21 insertions(+), 13 deletions(-)
> 
> diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
> index c3b210ede1..d02730004a 100644
> --- a/block/qcow2-bitmap.c
> +++ b/block/qcow2-bitmap.c
> @@ -435,7 +435,8 @@ static inline Qcow2BitmapDirEntry *next_dir_entry(Qcow2BitmapDirEntry *entry)
>      return (Qcow2BitmapDirEntry *)((uint8_t *)entry + dir_entry_size(entry));
>  }
>  
> -static int check_dir_entry(BlockDriverState *bs, Qcow2BitmapDirEntry *entry)
> +static int check_dir_entry(BlockDriverState *bs, Qcow2BitmapDirEntry *entry,
> +                           bool allow_resize)
>  {
>      BDRVQcow2State *s = bs->opaque;
>      uint64_t phys_bitmap_bytes;
> @@ -462,8 +463,14 @@ static int check_dir_entry(BlockDriverState *bs, Qcow2BitmapDirEntry *entry)
>          return len;

Someday, it would be nice to plumb Error* through this function, so that
you can give distinct reasons for failure, rather than lumping all
failures into the nebulous "doesn't meet the constraints" because we
lost context when slamming multiple errors into a single -EINVAL. But
that's a separate patch series.

>      }
>  
> -    fail = (phys_bitmap_bytes > BME_MAX_PHYS_SIZE) ||
> -           (len > ((phys_bitmap_bytes * 8) << entry->granularity_bits));
> +    if (phys_bitmap_bytes > BME_MAX_PHYS_SIZE) {
> +        return -EINVAL;
> +    }
> +
> +    if (!allow_resize &&
> +        (len > ((phys_bitmap_bytes * 8) << entry->granularity_bits))) {
> +        return -EINVAL;
> +    }
>  
>      return fail ? -EINVAL : 0;

Dead conditional - with your refactoring, this line is only reached when
fail == false.

With it changed to 'return 0',
Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-03-06 12:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05 23:43 [Qemu-devel] [PATCH 0/5] block/qcow2-bitmap: Enable resize with persistent bitmaps John Snow
2019-03-05 23:43 ` [Qemu-devel] [PATCH 1/5] block/qcow2-bitmap: Skip length check in some cases John Snow
2019-03-06 12:34   ` Eric Blake [this message]
2019-03-06 15:21   ` Vladimir Sementsov-Ogievskiy
2019-03-06 15:35     ` John Snow
2019-03-06 16:07   ` Vladimir Sementsov-Ogievskiy
2019-03-08 22:10     ` John Snow
2019-03-05 23:43 ` [Qemu-devel] [PATCH 2/5] block/qcow2-bitmap: Allow bitmap flushing John Snow
2019-03-06 12:58   ` Eric Blake
2019-03-06 15:59     ` John Snow
2019-03-06 16:12       ` Vladimir Sementsov-Ogievskiy
2019-03-08 22:11         ` John Snow
2019-03-05 23:43 ` [Qemu-devel] [PATCH 3/5] block/qcow2-bitmap: don't remove bitmaps on reopen John Snow
2019-03-06 15:28   ` Vladimir Sementsov-Ogievskiy
2019-03-06 15:38     ` John Snow
2019-03-05 23:43 ` [Qemu-devel] [PATCH 4/5] block/qcow2-bitmap: Allow resizes with persistent bitmaps John Snow
2019-03-06 15:33   ` Vladimir Sementsov-Ogievskiy
2019-03-06 15:36     ` Eric Blake
2019-03-06 15:44       ` Vladimir Sementsov-Ogievskiy
2019-03-06 15:41     ` John Snow
2019-03-06 15:52       ` Vladimir Sementsov-Ogievskiy
2019-03-06 15:56         ` Vladimir Sementsov-Ogievskiy
2019-03-09  0:35         ` John Snow
2019-03-05 23:43 ` [Qemu-devel] [PATCH 5/5] tests/qemu-iotests: add bitmap resize test 246 John Snow
2019-03-06  0:02 ` [Qemu-devel] [PATCH 0/5] block/qcow2-bitmap: Enable resize with persistent bitmaps John Snow
2019-03-10 16:50 ` no-reply
2019-03-11 16:18 ` Eric Blake
2019-03-11 17:36   ` Vladimir Sementsov-Ogievskiy
2019-03-11 17:48     ` Eric Blake
2019-03-11 18:05       ` Vladimir Sementsov-Ogievskiy
2019-03-11 18:05     ` John Snow
2019-03-11 18:26       ` Vladimir Sementsov-Ogievskiy
2019-03-11 18:35         ` John Snow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dfc7c39d-78df-b576-6e24-96846bb31193@redhat.com \
    --to=eblake@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).