All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Mike Day <ncmike@ncultra.org>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] qemu-img fails to delete last snapshot
Date: Thu, 15 May 2014 01:54:05 +0200	[thread overview]
Message-ID: <5374021D.6090309@redhat.com> (raw)
In-Reply-To: <1399926438-32292-1-git-send-email-ncmike@ncultra.org>

On 12.05.2014 22:27, Mike Day wrote:
> When deleting the last snapshot, copying the resulting snapshot table
> currently fails, causing the delete operation to also fail. Fix the
> failure by skipping the copy and just writing the snapshot header and
> freeing the extra clusters.
>
> There are two specific problems in the current code. First is a lack of
> parenthesis in the calculation of the memmove size parameter:
>
> s->nb_snapshots - snapshot_index - 1
>
> When s->nb_snapshots is 0, snapshot_index is 1.

Before this patch is applied, s->nb_snapshots is only increased after 
the memmove(). Therefore, it can never be 0 – snapshot_index on the 
other hand needs to be 0, as find_snapshot_by_id_and_name() forces it to 
be less than s->nb_snapshots (to elaborate on Kevin's review).

> 0 - 1 - 1 = 0xfffffffe
>
> it should be:
>
> 0 - (1 - 1) = 0x00
>
> The second problem is shifting the snapshot table to the left. After
> removing the last snapshot there are no existing snapshots to be
> shifted. All that needs to be done is to write the header and
> unallocate the blocks.
>
> Signed-off-by: Mike Day <ncmike@ncultra.org>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> ---
> v2: improved the git log entry
>      added Eric Blake as a reviewer

I do agree that this code is rather ugly and I had problems with it on 
more than one occasion (which should be speaking for itself, considering 
that I have not worked that long on qemu). On the other hand it is 
always a nice test case whether one broke zero-size allocations, though 
(while I'm not sure whether these should be allowed in the first place, 
though…).

Considering that this code indeed does perform a zero-size allocation 
reproducably, I'm rather surprised that we actually do not have a test 
case yet for snapshot deletion, though (as far as I can see).

So, all in all, I am kind of in favor of making the deletion of the last 
snapshot a special case as this would probably greatly improve 
readability; but on the other hand, it actually is a good test as it is 
right now.

Max

      parent reply	other threads:[~2014-05-14 23:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-12 20:27 [Qemu-devel] [PATCH v2] qemu-img fails to delete last snapshot Mike Day
2014-05-14 15:15 ` Kevin Wolf
2014-05-15 13:07   ` Mike Day
2014-05-15 13:26     ` Kevin Wolf
2014-05-14 23:54 ` Max Reitz [this message]

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=5374021D.6090309@redhat.com \
    --to=mreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=ncmike@ncultra.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.