Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1780574

Summary: Data corruption with resizing short overlay over longer backing files
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Kevin Wolf <kwolf>
Component: qemu-kvmAssignee: Kevin Wolf <kwolf>
qemu-kvm sub component: Storage QA Contact: Xueqiang Wei <xuwei>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: medium CC: coli, jinzhao, juzhang, virt-maint
Version: 8.1Flags: pm-rhel: mirror+
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-4.2.0-25.module+el8.2.1+6972+1d0c04b6 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-28 07:12:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Kevin Wolf 2019-12-06 12:52:33 UTC
When extending the size of a short overlay over a longer backing file, the new area doesn't correctly read as zeros, but the backing file contents becomes visible.

Amongst others, this affects commit block jobs in a situation like the following:

base (10 GB) <- mid (5 GB) <- top (8 GB)

In this case, unallocated blocks in top in the area from 5 GB to 8 GB read as zeros before the commit operation. However, commit resizes mid to 8 GB and the data will suddenly be read from base instead of reading as zero. This is a corruption bug.


Reproducer:

qemu-img create -f qcow2 /tmp/base.qcow2 2M
qemu-img create -f qcow2 -b /tmp/base.qcow2 /tmp/mid.qcow2 1M
qemu-img create -f qcow2 -b /tmp/mid.qcow2 /tmp/top.qcow2 2M

qemu-io -c 'write -P1 0 2M' /tmp/base.qcow2
qemu-io -c 'read -P0 1M 1M' /tmp/top.qcow2
qemu-img commit /tmp/top.qcow2
qemu-io -c 'read -P0 1M 1M' /tmp/mid.qcow2


Actual result:

[...]
Image committed.
Pattern verification failed at offset 1048576, 1048576 bytes
read 1048576/1048576 bytes at offset 1048576
1 MiB, 1 ops; 00.00 sec (3.291 GiB/sec and 3370.1125 ops/sec)


Expected result:

No "Pattern verification failed" message.

Comment 1 Tingting Mao 2019-12-09 05:30:04 UTC
Reproduced this issue as below.


Tested with:
qemu-kvm-4.2.0-1.module+el8.2.0+4793+b09dd2fb
kernel-4.18.0-153.el8


Steps:
1. Create images.
# qemu-img create -f qcow2 /tmp/base.qcow2 2M
# qemu-img create -f qcow2 -b /tmp/base.qcow2 /tmp/mid.qcow2 1M
# qemu-img create -f qcow2 -b /tmp/mid.qcow2 /tmp/top.qcow2 2M

2. Write data to the base image.
# qemu-io -c 'write -P1 0 2M' /tmp/base.qcow2

3. Check the data info of top image.
# qemu-io -c 'read -P0 1M 1M' /tmp/top.qcow2
read 1048576/1048576 bytes at offset 1048576
1 MiB, 1 ops; 00.00 sec (10.087 GiB/sec and 10329.1913 ops/sec)

4. Commit top image.
# qemu-img commit /tmp/top.qcow2

5. Check the data info mid image
# qemu-io -c 'read -P0 1M 1M' /tmp/mid.qcow2
Pattern verification failed at offset 1048576, 1048576 bytes
read 1048576/1048576 bytes at offset 1048576
1 MiB, 1 ops; 00.00 sec (1.720 GiB/sec and 1761.0626 ops/sec)
# qemu-io -c 'read -P1 1M 1M' /tmp/mid.qcow2
read 1048576/1048576 bytes at offset 1048576
1 MiB, 1 ops; 00.00 sec (1.556 GiB/sec and 1593.0873 ops/sec)


Result.
As above. After step5, the read data should be "0" as step3 not "1".

Comment 2 Ademar Reis 2020-02-05 23:10:15 UTC
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

Comment 9 Xueqiang Wei 2020-06-10 09:16:03 UTC
Reproduced it with qemu-kvm-4.2.0-23.module+el8.2.1+6917+927fbb44

After step 5:
# qemu-io -c 'read -P0 1M 1M' /tmp/mid.qcow2
Pattern verification failed at offset 1048576, 1048576 bytes
read 1048576/1048576 bytes at offset 1048576
1 MiB, 1 ops; 00.00 sec (1.822 GiB/sec and 1866.0302 ops/sec)

# qemu-io -c 'read -P1 1M 1M' /tmp/mid.qcow2
read 1048576/1048576 bytes at offset 1048576
1 MiB, 1 ops; 00.00 sec (1.532 GiB/sec and 1569.1000 ops/sec)



Retested it with qemu-kvm-4.2.0-25.module+el8.2.1+6972+1d0c04b6, it works well. So set bug status to VERIFIED.


Versions:
kernel-4.18.0-193.1.2.el8_2.x86_64
qemu-kvm-4.2.0-25.module+el8.2.1+6972+1d0c04b6


Steps:
1. Create images.
# qemu-img create -f qcow2 /tmp/base.qcow2 2M
# qemu-img create -f qcow2 -b /tmp/base.qcow2 /tmp/mid.qcow2 1M
# qemu-img create -f qcow2 -b /tmp/mid.qcow2 /tmp/top.qcow2 2M

2. Write data to the base image.
# qemu-io -c 'write -P1 0 2M' /tmp/base.qcow2
wrote 2097152/2097152 bytes at offset 0
2 MiB, 1 ops; 00.06 sec (33.988 MiB/sec and 16.9939 ops/sec)

3. Check the data info of top image.
# qemu-io -c 'read -P0 1M 1M' /tmp/top.qcow2
read 1048576/1048576 bytes at offset 1048576
1 MiB, 1 ops; 00.00 sec (9.345 GiB/sec and 9569.5611 ops/sec)

4. Commit top image.
#  qemu-img commit /tmp/top.qcow2
Image committed.

5. Check the data info mid image
#  qemu-io -c 'read -P0 1M 1M' /tmp/mid.qcow2
read 1048576/1048576 bytes at offset 1048576
1 MiB, 1 ops; 00.00 sec (5.160 GiB/sec and 5283.8483 ops/sec)

# qemu-io -c 'read -P1 1M 1M' /tmp/mid.qcow2
Pattern verification failed at offset 1048576, 1048576 bytes
read 1048576/1048576 bytes at offset 1048576
1 MiB, 1 ops; 00.00 sec (4.842 GiB/sec and 4958.4236 ops/sec)

Result.
As above. After step5, the read data is "0" as step3 not "1".

Comment 11 errata-xmlrpc 2020-07-28 07:12:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:3172