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
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list