Re: [PATCH 2/2] virDomainGetBlockJobInfo: Fix corner case when qemu reports no info

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

 



On 09/09/2016 04:30 PM, John Ferlan wrote:

>>  
>> +    /* Fix job completeness reporting. If cur == end mgmt
>> +     * applications think job is completed. Except when both cur
>> +     * and end are zero, in which case qemu hasn't started the
>> +     * job yet. */
>> +    if (!info->cur && !info->end) {

We get here if qemu reports 0/0 (or if qemu reports nothing, and we end
up with 0/0 because we 0-initialized the object)...

>> +        if (rawInfo->ready > 0) {
>> +            info->cur = info->end = 1;

if qemu reported done (on a no-op job), then we fudge to 1/1 and the
caller knows we are done...

>> +        } else if (rawInfo->ready < 0) {
>> +            info->end = 1;

if qemu didn't tell us it was ready, then we fudge to 0/1.

I thought the original email thread was that if rawInfo->ready == 0
(qemu explicitly told us it is NOT done) that we want to fudge to 0/1,
and then the real question is that if qemu tells us nothing at all about
rawInfo->ready, then fudging MIGHT treat a no-op job as never ending, so
it was better to leave it at 0/0 (an application getting 0/0 when
talking to new-enough libvirt then knows it is talking to older qemu).
In other words, I think this condition is slightly better as
rawInfo->ready == 0, and leave the rawInfo->ready < 0 case as 0/0.

Or am I misremembering the results of the earlier thread?

>> +        }
> 
> Can info->ready == 0 ?  w/ info->cur = info->end = 0
> 
> If so, then we're in the same mess or some other weird condition.
> 
> Seems like "ready" will be set in qemu during block_job_event_ready, so
> that would say to me that as long as the structure is allocated, ready
> will be false and conceivably info->cur = info->end = 0.
> 
> Wouldn't that mean the < 0 should be <= 0

<= 0 would make both explicitly not done and no answer from qemu mean
the same thing - we fudge to 0/1 to tell the caller that it is not done.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]