On 20.05.2013 18:25, Eric Blake wrote:
> On 05/19/2013 03:51 AM, Michal Privoznik wrote:
>>
>> I think I know where the bug is. When waiting on tray to open, we don't
>> unlock the domain. So later, when an event arrives, the first thing that the
>> event handler does is locking the domain. Hence, it seems like the event is
>> delivered right after we've failed waiting. That's just because after we've
>> finished waiting, we've unlocked the domain. And I think same applies for
>> the domain monitor. So can you please try this out:
>>
>> diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
>> index d037c9d..767d5a1 100644
>> --- a/src/qemu/qemu_hotplug.c
>> +++ b/src/qemu/qemu_hotplug.c
>> @@ -95,14 +95,20 @@ int qemuDomainChangeEjectableMedia(virQEMUDriverPtr
>> driver,
>> qemuDomainObjEnterMonitor(driver, vm);
>> ret = qemuMonitorEjectMedia(priv->mon, driveAlias, force);
>>
>> + virObjectRef(vm);
>> /* we don't want to report errors from media tray_open polling */
>> while (retries--) {
>> if (origdisk->tray_status == VIR_DOMAIN_DISK_TRAY_OPEN)
>> break;
>>
>> + qemuDomainObjExitMonitor(driver, vm);
>> + virObjectUnlock(vm);
>> VIR_DEBUG("Waiting 500ms for tray to open. Retries left %d",
>> retries);
>> usleep(500 * 1000); /* sleep 500ms */
>
> Yep, we absolutely must NOT usleep() while holding locks.
>
>> + virObjectLock(vm);
>> + qemuDomainObjEnterMonitor(driver, vm);
>> }
>> + virObjectUnref(vm);
>
> ACK
>
In fact, I am gonna be sending a slightly modified & more readable
version in a little while.
Michal
--
libvir-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list
