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

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