qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-block] help debugging throttle crash


From: Eric Blake
Subject: [Qemu-block] help debugging throttle crash
Date: Mon, 3 Apr 2017 09:07:02 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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



Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]