I'm trying to investigate https://bugzilla.redhat.com/show_bug.cgi?id=1428810, which is a crash that can be easily reproduced with the following steps:
$ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio
-device virtio-scsi-pci,bus=pci.0 -drive
id=drive_image2,if=none,format=raw,file=file2,bps=512000,iops=100,group=foo
-device scsi-hd,id=image2,drive=drive_image2 -drive
id=drive_image3,if=none,format=raw,file=file3,bps=512000,iops=100,group=foo
-device scsi-hd,id=image3,drive=drive_image3
{'execute':'qmp_capabilities'}
{'execute':'device_del','arguments':{'id':'image3'}}
{'execute':'system_reset'}
At this point, it looks like no one is calling
throttle_group_unregister_blk() as a result of the 'device_del', which
leaves stale memory around (I was able to confirm this under gcc - a
breakpoint on that function never fires); then the 'system_reset' causes
next_throttle_token() to dereference the stale memory and crash.
However, I have no idea where the unplug action should be removing the
BB from the throttle group. Is it as simple as adding it to
blk_io_unplug(), or will that be violating other constraints on making
sure the throttle group is first drained before removing the BB from the
group as one of the final steps during its hot unplug?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
