kernel stacktrace on volume detach in kvm guest
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Invalid
|
Undecided
|
Unassigned | ||
linux (Ubuntu) |
Fix Released
|
Medium
|
Stefan Bader | ||
qemu-kvm (Ubuntu) |
Invalid
|
Low
|
Unassigned |
Bug Description
Binary package hint: qemu-kvm
I'm using eucalyptus, an install post beta
I do (cc$ indicates cloud controller, instance$ indicates in instance)
- cc$ euca-create-volume -s 1 -z sm-zone-1a
- cc$ euca-attach-volume -i i-4AA8096D -d sdb vol-32F804B0
- instance$ sudo mkfs.ext4 -F /dev/sdb
- instance$ sudo mount /dev/sdb /mnt
- instance$ echo "hello world" | tee /mnt/foo
- instance$ sudo umount /mnt
- instance$ sudo mount /dev/sdb /mnt
- instance$ cat /mnt/foo
- instance$ sudo umount /mnt
- cc$ euca-detach-volume vol-32F804B0
And the instance sees a kernel stack trace in dmesg.
$ dpkg-query --show qemu-kvm "*euca*"
euca2ools 1.0+bzr20091007
eucalyptus-common 1.6~bzr931-0ubuntu2
eucalyptus-gl 1.6~bzr931-0ubuntu2
eucalyptus-nc 1.6~bzr931-0ubuntu2
qemu-kvm 0.11.0-0ubuntu5
the UEC image was 20091022 (RC)
CVE References
Changed in qemu-kvm (Ubuntu): | |
importance: | Undecided → Low |
status: | New → Confirmed |
Changed in linux (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in qemu: | |
status: | Confirmed → Invalid |
For the record, IRC snippit:
<smoser> i think i might have been missing some step to explicitly release /dev/sdb from the guest (maybe 'eject /dev/sdb' or something)
<kirkland> smoser: the stack trace on detach?
<kirkland> smoser: i've seen that, clearly wrong, but I haven't noticed any mal-effects
Subsequently, I did:
cc$ euca-attach-volume -i i-4AA8096D -d sdb vol-32F804B0
instance$ sudo mount /dev/sdb /mnt
instance$ # verifiy file is there
instance$ sudo umount /mnt
cc$ euca-detach-volume vol-32F804B0
instance$ grep sdb /proc/partitions || echo "IT IS STILL THERE"
# it wasn't still there.
So, this does indeed not seem to affect re-attaching the volume with the same device name.