thebeanogamer / rpms / qemu-kvm

Forked from rpms/qemu-kvm 5 months ago
Clone

Blame SOURCES/kvm-qcow2-Respect-new_block-in-alloc_refcount_block.patch

9ae3a8
From 9bffc974294d823d42b4b4d51e44abd26f7147a6 Mon Sep 17 00:00:00 2001
9ae3a8
From: Max Reitz <mreitz@redhat.com>
9ae3a8
Date: Sat, 13 Jun 2015 16:22:33 +0200
9ae3a8
Subject: [PATCH 39/42] qcow2: Respect new_block in alloc_refcount_block()
9ae3a8
9ae3a8
Message-id: <1434212556-3927-40-git-send-email-mreitz@redhat.com>
9ae3a8
Patchwork-id: 66058
9ae3a8
O-Subject: [RHEL-7.2 qemu-kvm PATCH 39/42] qcow2: Respect new_block in alloc_refcount_block()
9ae3a8
Bugzilla: 1129893
9ae3a8
RH-Acked-by: Jeffrey Cody <jcody@redhat.com>
9ae3a8
RH-Acked-by: Fam Zheng <famz@redhat.com>
9ae3a8
RH-Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
9ae3a8
9ae3a8
BZ: 1129893
9ae3a8
9ae3a8
When choosing a new place for the refcount table, alloc_refcount_block()
9ae3a8
tries to infer the number of clusters used so far from its argument
9ae3a8
cluster_index (which comes from the idea that if any cluster with an
9ae3a8
index greater than cluster_index was in use, the refcount table would
9ae3a8
have to be big enough already to describe cluster_index).
9ae3a8
9ae3a8
However, there is a cluster that may be at or after cluster_index, and
9ae3a8
which is not covered by the refcount structures, and that is the new
9ae3a8
refcount block new_block. Therefore, it should be taken into account for
9ae3a8
the blocks_used calculation.
9ae3a8
9ae3a8
Also, because new_block already describes (or is intended to describe)
9ae3a8
cluster_index, we may not put the new refcount structures there.
9ae3a8
9ae3a8
Signed-off-by: Max Reitz <mreitz@redhat.com>
9ae3a8
Message-id: 1423598552-24301-2-git-send-email-mreitz@redhat.com
9ae3a8
Reviewed-by: Eric Blake <eblake@redhat.com>
9ae3a8
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
9ae3a8
Signed-off-by: Max Reitz <mreitz@redhat.com>
9ae3a8
(cherry picked from commit 14a58a4e0c2e98a7d9232e1c229a531ca231133b)
9ae3a8
9ae3a8
Signed-off-by: Max Reitz <mreitz@redhat.com>
9ae3a8
Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
9ae3a8
---
9ae3a8
 block/qcow2-refcount.c | 16 ++++++++++++++--
9ae3a8
 1 file changed, 14 insertions(+), 2 deletions(-)
9ae3a8
9ae3a8
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
9ae3a8
index 87b932c..cee5b1f 100644
9ae3a8
--- a/block/qcow2-refcount.c
9ae3a8
+++ b/block/qcow2-refcount.c
9ae3a8
@@ -319,8 +319,20 @@ static int alloc_refcount_block(BlockDriverState *bs,
9ae3a8
      */
9ae3a8
     BLKDBG_EVENT(bs->file, BLKDBG_REFTABLE_GROW);
9ae3a8
 
9ae3a8
-    /* Calculate the number of refcount blocks needed so far */
9ae3a8
-    uint64_t blocks_used = DIV_ROUND_UP(cluster_index, s->refcount_block_size);
9ae3a8
+    /* Calculate the number of refcount blocks needed so far; this will be the
9ae3a8
+     * basis for calculating the index of the first cluster used for the
9ae3a8
+     * self-describing refcount structures which we are about to create.
9ae3a8
+     *
9ae3a8
+     * Because we reached this point, there cannot be any refcount entries for
9ae3a8
+     * cluster_index or higher indices yet. However, because new_block has been
9ae3a8
+     * allocated to describe that cluster (and it will assume this role later
9ae3a8
+     * on), we cannot use that index; also, new_block may actually have a higher
9ae3a8
+     * cluster index than cluster_index, so it needs to be taken into account
9ae3a8
+     * here (and 1 needs to be added to its value because that cluster is used).
9ae3a8
+     */
9ae3a8
+    uint64_t blocks_used = DIV_ROUND_UP(MAX(cluster_index + 1,
9ae3a8
+                                            (new_block >> s->cluster_bits) + 1),
9ae3a8
+                                        s->refcount_block_size);
9ae3a8
 
9ae3a8
     if (blocks_used > QCOW_MAX_REFTABLE_SIZE / sizeof(uint64_t)) {
9ae3a8
         return -EFBIG;
9ae3a8
-- 
9ae3a8
1.8.3.1
9ae3a8