Bug 513252

Summary: Asignation instead of comparation inside if
Product: Red Hat Enterprise Linux 5 Reporter: Juan Quintela <quintela>
Component: kvmAssignee: Juan Quintela <quintela>
Status: CLOSED ERRATA QA Contact: Lawrence Lim <llim>
Severity: medium Docs Contact:
Priority: high    
Version: 5.4CC: armbru, ehabkost, lihuang, sghosh, tburke, tools-bugs, virt-maint, ykaul
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kvm-83-96.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 09:28:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Change = for == none

Description Juan Quintela 2009-07-22 17:42:13 UTC
Description of problem:

Found during code inspection that we commited a bug:
An assignation instead of one comparation:

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Patch included

Comment 1 Juan Quintela 2009-07-22 17:52:16 UTC
Created attachment 354757 [details]
Change = for ==

Comment 4 Markus Armbruster 2009-07-22 23:37:40 UTC
Based on reading the code, I think this breaks the host_device driver
for image files with names matching "/dev/cd*" and "/dev/fd*".  We
lose the ability to detect empty drives, media change, to eject media,
and to lock the CD drive door.  Furthermore, we may erroneously
attempt to truncate the device file.

Device probing chooses the host_device driver for device special files
and files matching name "/dev/cdrom*".

Comment 5 Juan Quintela 2009-07-23 03:33:22 UTC
Boot with command line like:

[root@ninfa ~]# /usr/libexec/qemu-kvm -M pc -m 1024 -smp 1 -name test2
-drive file=/mnt/images/clone.img,if=ide,index=0,format=qcow2 -net
nic,macaddr=54:52:00:53:7e:5b,vlan=0,model=virtio -net
tap,script=/etc/kvm-ifup,vlan=0,ifname=vnet1,downscript=no --monitor
telnet:0:5555,server --serial telnet:0:5554,server -vnc :0 --drive
file=/dev/cdrom,if=ide,index=2

and then inside the guest:

[root@d12 ~]# mount /dev/hdc /mnt/
[root@d12 ~]# ls /mnt/
ESTOOL.EXE  run.bat
[root@d12 ~]# find /mnt/ -type f | xargs md6sum
xargs: md6sum: No such file or directory
[root@d12 ~]# find /mnt/ -type f | xargs md5sum
c2b9bf814fd95ad30318686f522ba07c  /mnt/ESTOOL.EXE
1f39cf0a481a30348280fc3c2283a01d  /mnt/run.bat
[root@d12 ~]# umount /mnt/
[root@d12 ~]# eject /dev/hdc
eject: unable to eject, last error: Invalid argument
[root@d12 ~]# 

dmesg and screen show:
ISO 9660 Extensions: Microsoft Joliet Level 3
ISOFS: changing to secondary root
SELinux: initialized (dev hdc, type iso9660), uses genfs_contexts
ide_do_rw_disk - bad command: dev hdc: flags = REQ_RW REQ_SOFTBARRIER REQ_NOMERGE REQ_STARTED REQ_ELVPRIV REQ_BLOCK_PC 
sector 308061, nr/cnr 8/8
bio 0000000000000000, biotail 0000000000000000, buffer 0000000000000000, data 0000000000000000, len 0
cdb: 1b 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 


and now the party:

Open the cdrom and take the disk out

[root@d12 ~]# mount /dev/hdc /mnt/
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 36
Buffer I/O error on device hdc, logical block 9
hdc: task_in_intr: status=0x41 { DriveReady Error }
hdc: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hdc: task_in_intr: status=0x41 { DriveReady Error }
hdc: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hdc: task_in_intr: status=0x41 { DriveReady Error }
hdc: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hdc: task_in_intr: status=0x41 { DriveReady Error }
hdc: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown

loads and loads of this error for a while.  Yes, I noticed it yesterday
night, not sure how nobody else catched it ever :(

I don't know how if this is directly related to what we have here, it also happens with this patch applied.

Comment 13 errata-xmlrpc 2009-09-02 09:28:10 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1272.html