From: Kevin Wolf <kwolf@redhat.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, vsementsov@virtuozzo.com,
qemu-devel@nongnu.org, mreitz@redhat.com, stefanha@redhat.com
Subject: [PATCH 2/6] block: truncate: Don't make backing file data visible
Date: Wed, 20 Nov 2019 15:03:15 +0100 [thread overview]
Message-ID: <20191120140319.1505-3-kwolf@redhat.com> (raw)
In-Reply-To: <20191120140319.1505-1-kwolf@redhat.com>
When extending the size of an image that has a backing file larger than
its old size, make sure that the backing file data doesn't become
visible in the guest, but the added area is properly zeroed out.
The old behaviour made a difference in 'block_resize' (where showing the
backing file data from an old snapshot rather than zeros is
questionable) as well as in commit block jobs (both from active and
intermediate nodes) and HMP 'commit', where committing to a short
backing file would incorrectly omit writing zeroes for unallocated
blocks on the top layer after the EOF of the short backing file.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
block/io.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/block/io.c b/block/io.c
index 003f4ea38c..8683f7a4bd 100644
--- a/block/io.c
+++ b/block/io.c
@@ -3382,6 +3382,31 @@ int coroutine_fn bdrv_co_truncate(BdrvChild *child, int64_t offset, bool exact,
goto out;
}
+ /*
+ * If the image has a backing file that is large enough that it would
+ * provide data for the new area, we cannot leave it unallocated because
+ * then the backing file content would become visible. Instead, zero-fill
+ * the area where backing file and new area overlap.
+ */
+ if (new_bytes && bs->backing && prealloc == PREALLOC_MODE_OFF) {
+ int64_t backing_len;
+
+ backing_len = bdrv_getlength(backing_bs(bs));
+ if (backing_len < 0) {
+ ret = backing_len;
+ goto out;
+ }
+
+ if (backing_len > old_size) {
+ ret = bdrv_co_do_pwrite_zeroes(bs, old_size,
+ MIN(new_bytes, backing_len - old_size),
+ BDRV_REQ_ZERO_WRITE | BDRV_REQ_MAY_UNMAP);
+ if (ret < 0) {
+ goto out;
+ }
+ }
+ }
+
ret = refresh_total_sectors(bs, offset >> BDRV_SECTOR_BITS);
if (ret < 0) {
error_setg_errno(errp, -ret, "Could not refresh total sector count");
--
2.20.1
next prev parent reply other threads:[~2019-11-20 14:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 14:03 [PATCH for-4.2? 0/6] block: Fix resize (extending) of short overlays Kevin Wolf
2019-11-20 14:03 ` [PATCH 1/6] block: bdrv_co_do_pwrite_zeroes: 64 bit 'bytes' parameter Kevin Wolf
2019-11-20 14:14 ` Eric Blake
2019-11-20 14:27 ` Vladimir Sementsov-Ogievskiy
2019-11-20 16:18 ` Alberto Garcia
2019-11-20 14:03 ` Kevin Wolf [this message]
2019-11-20 14:20 ` [PATCH 2/6] block: truncate: Don't make backing file data visible Eric Blake
2019-11-20 14:47 ` Vladimir Sementsov-Ogievskiy
2019-11-20 15:12 ` Kevin Wolf
2019-11-20 18:01 ` Vladimir Sementsov-Ogievskiy
2019-11-25 11:06 ` Kevin Wolf
2019-11-20 14:03 ` [PATCH 3/6] iotests: Add qemu_io_log() Kevin Wolf
2019-11-20 14:26 ` Eric Blake
2019-11-20 14:49 ` Vladimir Sementsov-Ogievskiy
2019-11-20 14:03 ` [PATCH 4/6] iotests: Fix timeout in run_job() Kevin Wolf
2019-11-20 14:29 ` Eric Blake
2019-11-20 14:51 ` Vladimir Sementsov-Ogievskiy
2019-11-20 14:03 ` [PATCH 5/6] iotests: Support job-complete " Kevin Wolf
2019-11-20 14:46 ` Eric Blake
2019-11-20 14:56 ` Vladimir Sementsov-Ogievskiy
2019-11-20 14:03 ` [PATCH 6/6] iotests: Test committing to short backing file Kevin Wolf
2019-11-20 14:52 ` Eric Blake
2019-11-20 15:41 ` Vladimir Sementsov-Ogievskiy
2019-11-20 16:11 ` Kevin Wolf
2019-11-20 16:29 ` Vladimir Sementsov-Ogievskiy
2019-11-20 16:10 ` Vladimir Sementsov-Ogievskiy
2019-11-20 15:49 ` [PATCH for-4.2? 0/6] block: Fix resize (extending) of short overlays Vladimir Sementsov-Ogievskiy
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=20191120140319.1505-3-kwolf@redhat.com \
--to=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@virtuozzo.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).