From: Max Reitz <mreitz@redhat.com>
To: "Benoît Canet" <benoit.canet@irqsave.net>
Cc: Kevin Wolf <kwolf@redhat.com>, Laszlo Ersek <lersek@redhat.com>,
qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qcow2: Fix fail path in realloc_refcount_block()
Date: Mon, 17 Mar 2014 22:02:27 +0100 [thread overview]
Message-ID: <532762E3.9080907@redhat.com> (raw)
In-Reply-To: <20140315231604.GA3067@irqsave.net>
On 16.03.2014 00:16, Benoît Canet wrote:
> The Saturday 15 Mar 2014 à 21:55:54 (+0100), Max Reitz wrote :
>> If qcow2_alloc_clusters() fails, new_offset and ret will both be
>> negative after the fail label, thus passing the first if condition and
>> subsequently resulting in a call of qcow2_free_clusters() with an
>> invalid (negative) offset parameter. Fix this by checking for new_offset
>> being positive instead.
>>
>> While we're at it, clean up the whole fail path. qcow2_cache_put()
>> actually can never fail, hence the return value can safely be ignored
> I would say "actually should never fail".
Hm, I'm not sure. Currently, it simply cannot fail. The assertion is
there basically only for future code changes and to indicate to
developers that the function is really known to succeed.
I'll try to make the sentence more specific.
>> (aside from asserting that it indeed did not fail).
>>
>> Furthermore, there is no reason to give QCOW2_DISCARD_ALWAYS to
>> qcow2_free_clusters(), a mere QCOW2_DISCARD_OTHER will suffice.
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> Suggested-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>> block/qcow2-refcount.c | 20 +++++++++++---------
>> 1 file changed, 11 insertions(+), 9 deletions(-)
>>
>> diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
>> index 6151148..b111319 100644
>> --- a/block/qcow2-refcount.c
>> +++ b/block/qcow2-refcount.c
>> @@ -1440,20 +1440,22 @@ static int64_t realloc_refcount_block(BlockDriverState *bs, int reftable_index,
>> }
>>
>> fail:
> I don't like the label name because its real meaning is exit: it handle both
> fail and regular exits.
I'll try to reshape it into a nicer form of nested labels.
>> - if (new_offset && (ret < 0)) {
>> - qcow2_free_clusters(bs, new_offset, s->cluster_size,
>> - QCOW2_DISCARD_ALWAYS);
>> - }
>> if (refcount_block) {
>> - if (ret < 0) {
>> - qcow2_cache_put(bs, s->refcount_block_cache, &refcount_block);
>> - } else {
>> - ret = qcow2_cache_put(bs, s->refcount_block_cache, &refcount_block);
>> - }
>> + /* This should never fail, as it would only do so if the given refcount
>> + * block cannot be found in the cache. As this is impossible as long as
>> + * there are no bugs, assert the success. */
>> + int tmp = qcow2_cache_put(bs, s->refcount_block_cache, &refcount_block);
>> + assert(tmp == 0);
>> }
>> +
>> if (ret < 0) {
>> + if (new_offset > 0) {
>> + qcow2_free_clusters(bs, new_offset, s->cluster_size,
>> + QCOW2_DISCARD_OTHER);
>> + }
>> return ret;
>> }
>> +
>> return new_offset;
> The function documentation says:
> /*
> * Allocates a new cluster for the given refcount block (represented by its
> * offset in the image file) and copies the current content there. This function
> * does _not_ decrement the reference count for the currently occupied cluster.
> *
> * This function prints an informative message to stderr on error (and returns
> * -errno); on success, 0 is returned.
> */
> static int64_t realloc_refcount_block(BlockDriverState *bs, int reftable_index,
> uint64_t offset)
>
>
> So why are we returning new_offset on success ?
Because the comment is wrong. I'll fix it. ;-)
Thanks,
Max
>> }
>>
>> --
>> 1.9.0
>>
>>
next prev parent reply other threads:[~2014-03-17 21:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-15 20:55 [Qemu-devel] [PATCH] qcow2: Fix fail path in realloc_refcount_block() Max Reitz
2014-03-15 23:16 ` Benoît Canet
2014-03-17 21:02 ` Max Reitz [this message]
2014-03-15 23:26 ` Benoît Canet
2014-03-17 10:23 ` Laszlo Ersek
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=532762E3.9080907@redhat.com \
--to=mreitz@redhat.com \
--cc=benoit.canet@irqsave.net \
--cc=kwolf@redhat.com \
--cc=lersek@redhat.com \
--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 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).