qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH v4 5/5] vmdk: Reject excess extents in blockdev-create
Date: Fri, 7 Dec 2018 15:54:17 +0100	[thread overview]
Message-ID: <20181207145417.GG5119@linux.fritz.box> (raw)
In-Reply-To: <87k1klwkft.fsf@dusky.pond.sub.org>

Am 07.12.2018 um 14:11 hat Markus Armbruster geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
> > Clarify that the number of extents provided in BlockdevCreateOptionsVmdk
> > must match the number of extents that will actually be used. Providing
> > more extents will result in an error now.
> >
> > This requires adapting the test case to provide the right number of
> > extents.
> >
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> >  qapi/block-core.json       |  3 ++-
> >  block/vmdk.c               | 29 ++++++++++++++++++++++++-----
> >  tests/qemu-iotests/237     |  6 +++++-
> >  tests/qemu-iotests/237.out | 13 +++++++------
> >  4 files changed, 38 insertions(+), 13 deletions(-)
> >
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index 0793550cf2..afdd2f89a2 100644
> > --- a/qapi/block-core.json
> > +++ b/qapi/block-core.json
> > @@ -4068,7 +4068,8 @@
> >  #               twoGbMaxExtentSparse and twoGbMaxExtentFlat formats. For
> >  #               monolithicFlat, only one entry is required; for
> >  #               twoGbMaxExtent* formats, the number of entries required is
> > -#               calculated as extent_number = virtual_size / 2GB.
> > +#               calculated as extent_number = virtual_size / 2GB. Providing
> > +#               more extents than will be used is an error.
> >  # @subformat    The subformat of the VMDK image. Default: "monolithicSparse".
> >  # @backing-file The path of backing file. Default: no backing file is used.
> >  # @adapter-type The adapter type used to fill in the descriptor. Default: ide.
> > diff --git a/block/vmdk.c b/block/vmdk.c
> > index 5a162ee85c..682ad93aa1 100644
> > --- a/block/vmdk.c
> > +++ b/block/vmdk.c
> > @@ -1970,6 +1970,7 @@ static int coroutine_fn vmdk_co_do_create(int64_t size,
> >  {
> >      int extent_idx;
> >      BlockBackend *blk = NULL;
> > +    BlockBackend *extent_blk;
> >      Error *local_err = NULL;
> >      char *desc = NULL;
> >      int ret = 0;
> > @@ -2107,7 +2108,6 @@ static int coroutine_fn vmdk_co_do_create(int64_t size,
> >      }
> >      extent_idx = 1;
> >      while (created_size < size) {
> > -        BlockBackend *extent_blk;
> >          int64_t cur_size = MIN(size - created_size, extent_size);
> >          extent_blk = extent_fn(cur_size, extent_idx, flat, split, compress,
> >                                 zeroed_grain, opaque, errp);
> > @@ -2121,6 +2121,17 @@ static int coroutine_fn vmdk_co_do_create(int64_t size,
> >          extent_idx++;
> >          blk_unref(extent_blk);
> >      }
> > +
> > +    /* Check whether we got excess extents */
> > +    extent_blk = extent_fn(-1, extent_idx, flat, split, compress, zeroed_grain,
> > +                           opaque, NULL);
> > +    if (extent_blk) {
> > +        blk_unref(extent_blk);
> > +        error_setg(errp, "List of extents contains unused extents");
> > +        ret = -EINVAL;
> > +        goto exit;
> > +    }
> > +
> >      /* generate descriptor file */
> >      desc = g_strdup_printf(desc_template,
> >                             g_random_int(),
> > @@ -2181,6 +2192,12 @@ static BlockBackend *vmdk_co_create_opts_cb(int64_t size, int idx,
> >      char *ext_filename = NULL;
> >      char *rel_filename = NULL;
> >  
> > +    /* We're done, don't create excess extents. */
> > +    if (size == -1) {
> > +        assert(errp == NULL);
> > +        return NULL;
> > +    }
> > +
> 
> I'm afraid I don't get this hunk.

vmdk_co_create_opts_cb() is for the legacy code path, where 'qemu-img
create' passes us a QemuOpts. This doesn't contain extents, so rather
than returning ther next extent from the input, this function simply
creates a new extent file each time it is called.

When checking whether we have too many extents, we don't know from which
code path we came, so we have to call the callback uncondtionally and
see whether it still returns an extra extent. In this case, creating a
new one would obviously be counterproductive and trigger an error, so I
just return NULL immediately.

If you have a suggestion for a comment to put somewhere, I'll gladly add
it.

Kevin

  reply	other threads:[~2018-12-07 14:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07 11:53 [Qemu-devel] [PATCH v4 0/5] vmdk: Implement blockdev-create Kevin Wolf
2018-12-07 11:53 ` [Qemu-devel] [PATCH v4 1/5] vmdk: Refactor vmdk_create_extent Kevin Wolf
2018-12-07 11:53 ` [Qemu-devel] [PATCH v4 2/5] vmdk: Implement .bdrv_co_create callback Kevin Wolf
2018-12-07 13:01   ` Markus Armbruster
2018-12-07 13:04     ` Markus Armbruster
2018-12-07 11:53 ` [Qemu-devel] [PATCH v4 3/5] iotests: Filter cid numbers in VMDK extent info Kevin Wolf
2018-12-07 11:53 ` [Qemu-devel] [PATCH v4 4/5] iotests: Add VMDK tests for blockdev-create Kevin Wolf
2018-12-07 13:02   ` Markus Armbruster
2018-12-07 13:12   ` Markus Armbruster
2018-12-07 14:45     ` Kevin Wolf
2018-12-07 15:40       ` Eric Blake
2018-12-07 16:42         ` Kevin Wolf
2018-12-07 16:52           ` Eric Blake
2018-12-07 17:09             ` Kevin Wolf
2018-12-07 11:53 ` [Qemu-devel] [PATCH v4 5/5] vmdk: Reject excess extents in blockdev-create Kevin Wolf
2018-12-07 13:11   ` Markus Armbruster
2018-12-07 14:54     ` Kevin Wolf [this message]
2018-12-07 15:34       ` Markus Armbruster
2018-12-07 12:56 ` [Qemu-devel] [PATCH v4 0/5] vmdk: Implement blockdev-create no-reply

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=20181207145417.GG5119@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).