thebeanogamer / rpms / qemu-kvm

Forked from rpms/qemu-kvm 5 months ago
Clone

Blame SOURCES/kvm-block-truncate-Don-t-make-backing-file-data-visible.patch

77c23f
From d84b9b93755ece6618ed98fa84386beeb1a0e40b Mon Sep 17 00:00:00 2001
77c23f
From: Kevin Wolf <kwolf@redhat.com>
77c23f
Date: Mon, 8 Jun 2020 15:01:36 +0100
77c23f
Subject: [PATCH 08/17] block: truncate: Don't make backing file data visible
77c23f
77c23f
RH-Author: Kevin Wolf <kwolf@redhat.com>
77c23f
Message-id: <20200608150140.38218-8-kwolf@redhat.com>
77c23f
Patchwork-id: 97454
77c23f
O-Subject: [RHEL-AV-8.2.1 qemu-kvm PATCH 07/11] block: truncate: Don't make backing file data visible
77c23f
Bugzilla: 1780574
77c23f
RH-Acked-by: Sergio Lopez Pascual <slp@redhat.com>
77c23f
RH-Acked-by: Eric Blake <eblake@redhat.com>
77c23f
RH-Acked-by: Max Reitz <mreitz@redhat.com>
77c23f
77c23f
When extending the size of an image that has a backing file larger than
77c23f
its old size, make sure that the backing file data doesn't become
77c23f
visible in the guest, but the added area is properly zeroed out.
77c23f
77c23f
Consider the following scenario where the overlay is shorter than its
77c23f
backing file:
77c23f
77c23f
    base.qcow2:     AAAAAAAA
77c23f
    overlay.qcow2:  BBBB
77c23f
77c23f
When resizing (extending) overlay.qcow2, the new blocks should not stay
77c23f
unallocated and make the additional As from base.qcow2 visible like
77c23f
before this patch, but zeros should be read.
77c23f
77c23f
A similar case happens with the various variants of a commit job when an
77c23f
intermediate file is short (- for unallocated):
77c23f
77c23f
    base.qcow2:     A-A-AAAA
77c23f
    mid.qcow2:      BB-B
77c23f
    top.qcow2:      C--C--C-
77c23f
77c23f
After commit top.qcow2 to mid.qcow2, the following happens:
77c23f
77c23f
    mid.qcow2:      CB-C00C0 (correct result)
77c23f
    mid.qcow2:      CB-C--C- (before this fix)
77c23f
77c23f
Without the fix, blocks that previously read as zeros on top.qcow2
77c23f
suddenly turn into A.
77c23f
77c23f
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
77c23f
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
77c23f
Message-Id: <20200424125448.63318-8-kwolf@redhat.com>
77c23f
Reviewed-by: Max Reitz <mreitz@redhat.com>
77c23f
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
77c23f
(cherry picked from commit 955c7d6687fefcd903900a1e597fcbc896c661cd)
77c23f
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
77c23f
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
77c23f
---
77c23f
 block/io.c | 25 +++++++++++++++++++++++++
77c23f
 1 file changed, 25 insertions(+)
77c23f
77c23f
diff --git a/block/io.c b/block/io.c
77c23f
index 3235ce5..6c70b56 100644
77c23f
--- a/block/io.c
77c23f
+++ b/block/io.c
77c23f
@@ -3370,6 +3370,31 @@ int coroutine_fn bdrv_co_truncate(BdrvChild *child, int64_t offset, bool exact,
77c23f
         goto out;
77c23f
     }
77c23f
 
77c23f
+    /*
77c23f
+     * If the image has a backing file that is large enough that it would
77c23f
+     * provide data for the new area, we cannot leave it unallocated because
77c23f
+     * then the backing file content would become visible. Instead, zero-fill
77c23f
+     * the new area.
77c23f
+     *
77c23f
+     * Note that if the image has a backing file, but was opened without the
77c23f
+     * backing file, taking care of keeping things consistent with that backing
77c23f
+     * file is the user's responsibility.
77c23f
+     */
77c23f
+    if (new_bytes && bs->backing) {
77c23f
+        int64_t backing_len;
77c23f
+
77c23f
+        backing_len = bdrv_getlength(backing_bs(bs));
77c23f
+        if (backing_len < 0) {
77c23f
+            ret = backing_len;
77c23f
+            error_setg_errno(errp, -ret, "Could not get backing file size");
77c23f
+            goto out;
77c23f
+        }
77c23f
+
77c23f
+        if (backing_len > old_size) {
77c23f
+            flags |= BDRV_REQ_ZERO_WRITE;
77c23f
+        }
77c23f
+    }
77c23f
+
77c23f
     if (drv->bdrv_co_truncate) {
77c23f
         if (flags & ~bs->supported_truncate_flags) {
77c23f
             error_setg(errp, "Block driver does not support requested flags");
77c23f
-- 
77c23f
1.8.3.1
77c23f