Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1807057

Summary: qcow2_alloc_cluster_abort() frees preallocated zero clusters
Product: Red Hat Enterprise Linux 8 Reporter: Hanna Czenczek <hreitz>
Component: qemu-kvmAssignee: Hanna Czenczek <hreitz>
qemu-kvm sub component: qcow2 QA Contact: Xueqiang Wei <xuwei>
Status: CLOSED ERRATA Docs Contact:
Severity: low    
Priority: low CC: coli, jinzhao, juzhang, virt-maint, xuwei
Version: 8.2Keywords: Triaged
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-4.2.0-31.module+el8.3.0+7437+4bb96e0d Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1807377 (view as bug list) Environment:
Last Closed: 2020-11-04 02:53:03 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:
Bug Depends On:    
Bug Blocks: 1807377    

Description Hanna Czenczek 2020-02-25 14:40:13 UTC 
Description of problem:

qcow2_alloc_cluster_abort() frees preallocated zero clusters, even though the corresponding handle_alloc() did not allocate them.  This leads to image corruption.


Version-Release number of selected component (if applicable):

qemu-kvm-4.2.0-12.module+el8.2.0+5858+afd073bc


How reproducible:

Always


Steps to Reproduce:

Create a preallocated zero cluster, then issue a write to it while ensuring that the data write will fail:

$ cat > blkdebug.conf <<EOF
[inject-error]
event = "write_aio"
errno = "5"
immediately = "on"
once = "on"
EOF

$ qemu-img create -f qcow2 foo.qcow2 64M
$ qemu-io -c 'write 0 64k' -c 'write -z 0 64k' foo.qcow2
$ qemu-io -c 'write 0 64k' blkdebug:blkdebug.conf:foo.qcow2


Actual results:

$ qemu-img check foo.qcow2
ERROR cluster 5 refcount=0 reference=1
ERROR OFLAG_COPIED data cluster: l2_entry=8000000000050001 refcount=0

2 errors were found on the image.
Data may be corrupted, or further writes to the image may corrupt it.
1/1024 = 0.10% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 393216


Expected results:

$ qemu-img check foo.qcow2
No errors were found on the image.
1/1024 = 0.10% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 393216


Additional info:

Fix sent upstream as “qcow2: Fix alloc_cluster_abort() for pre-existing clusters”.
Comment 2 Hanna Czenczek 2020-02-26 09:01:00 UTC 
Oh.  I actually meant to create this BZ for AV.  I didn’t even know this bug existed in the slow train, too, but it does indeed.

Well, then I think we should keep this one for the slow train and create a new one for the fast train, yes.

And as for:
(In reply to Max Reitz from comment #0)
> Version-Release number of selected component (if applicable):
> 
> qemu-kvm-4.2.0-12.module+el8.2.0+5858+afd073bc

So this should be qemu-kvm-2.12.0-99.module+el8.2.0+5827+8c39933c for this BZ.

Max
Comment 9 Xueqiang Wei 2020-07-23 06:35:42 UTC 
Reproduced it with qemu-kvm-4.2.0-30.module+el8.3.0+7298+c26a06b8

# cat > blkdebug.conf <<EOF
[inject-error]
event = "write_aio"
errno = "5"
immediately = "on"
once = "on"
EOF

# qemu-img create -f qcow2 foo.qcow2 64M
Formatting 'foo.qcow2', fmt=qcow2 size=67108864 cluster_size=65536 lazy_refcounts=off refcount_bits=16

# qemu-io -c 'write 0 64k' -c 'write -z 0 64k' foo.qcow2
wrote 65536/65536 bytes at offset 0
64 KiB, 1 ops; 00.06 sec (1.041 MiB/sec and 16.6579 ops/sec)
wrote 65536/65536 bytes at offset 0
64 KiB, 1 ops; 00.01 sec (11.074 MiB/sec and 177.1867 ops/sec)

# qemu-io -c 'write 0 64k' blkdebug:blkdebug.conf:foo.qcow2
write failed: Input/output error

# qemu-img check foo.qcow2
ERROR cluster 5 refcount=0 reference=1
ERROR OFLAG_COPIED data cluster: l2_entry=8000000000050001 refcount=0

2 errors were found on the image.
Data may be corrupted, or further writes to the image may corrupt it.
1/1024 = 0.10% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 393216



Retested with qemu-kvm-4.2.0-31.module+el8.3.0+7437+4bb96e0d, not hit this issue. So set status to VERIFIED.

Versions:
kernel-4.18.0-224.el8.x86_64
qemu-kvm-4.2.0-31.module+el8.3.0+7437+4bb96e0d


# qemu-img create -f qcow2 foo.qcow2 64M
Formatting 'foo.qcow2', fmt=qcow2 size=67108864 cluster_size=65536 lazy_refcounts=off refcount_bits=16

# qemu-img create -f qcow2 foo.qcow2 64M
Formatting 'foo.qcow2', fmt=qcow2 size=67108864 cluster_size=65536 lazy_refcounts=off refcount_bits=16

# qemu-io -c 'write 0 64k' -c 'write -z 0 64k' foo.qcow2
wrote 65536/65536 bytes at offset 0
64 KiB, 1 ops; 00.06 sec (1.135 MiB/sec and 18.1635 ops/sec)
wrote 65536/65536 bytes at offset 0
64 KiB, 1 ops; 00.01 sec (11.082 MiB/sec and 177.3184 ops/sec)

# qemu-io -c 'write 0 64k' blkdebug:blkdebug.conf:foo.qcow2
write failed: Input/output error

# qemu-img check foo.qcow2
No errors were found on the image.
1/1024 = 0.10% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 393216
Comment 12 errata-xmlrpc 2020-11-04 02:53:03 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 (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), 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/RHSA-2020:4676