On 01/27/2015 12:48 PM, Eric Blake wrote:
On 01/19/2015 03:01 PM, John Ferlan wrote:
Revisiting, now that the release is done.
On 01/12/2015 05:54 PM, Eric Blake wrote:
At least with live block commit, it is possible to have a block job that reports 0 status: namely, when the active image contains no sectors that differ from the backing image it is being committed into [1]. I'm not sure if that represents a qemu bug, but it leads to weird virsh output where 'virsh blockjob $dom vda' has no output during a no-op commit job. It appears that the special case for a zero total was first introduced for migration, where it does sort of make sense (when we do storage migration, the job is broken up into two pieces where the first half of migrating storage has no clue what the total length of the second phase will be, and where qemu migration always reports a non-zero total length but only once we complete the first phase to start actual migration), but it doesn't seem to make sense for any of the block jobs.
@@ -1678,10 +1678,6 @@ vshPrintJobProgress(const char *label, unsigned long long remaining, { int progress;
- if (total == 0) - /* migration has not been started */ - return; -
Would it be necessarily true that remaining was zero at this point?
I've never seen a case where qemu (and thus libvirt) reported remaining
total.
Because if it wasn't then, the else condition will divide by zero if total == 0... More than 1 caller to this function...
So I think we are safe in avoiding the divide by 0 potential. Of the multiple callers, many are related to block jobs (where 0 status is likely synonymous with no work to do) and the only caller I modified (migration) is where 0 status means not yet started.
What about the following? - int progress; - - if (total == 0) - /* migration has not been started */ - return; + int progress = 0; if (remaining == 0) { /* migration has completed */ progress = 100; - } else { + } else if (remaining > 0) { That way if this is called by "others" which use "... info.end - info.cur, info.end);", we avoid the chance that info.end == 0 and there's a divide by zero. The remaining == 0 still means we're done, the remaining < 0 means perhaps we haven't started (no progress). The only question I'd have is how much of an infinite loop this could be if total never got > 0... John
Perhaps safer to say if "remaining == 0 || total == 0"?
I was just reviewing Michal's patch from last week:
http://www.redhat.com/archives/libvir-list/2015-January/msg00230.html
where it seems a zero could imply some sort of failure. If you did the total == 0 check, then the && jobinfo.dataTotal isn't necessary... I would suppose that an error would mean we're 100% done...
I'm also debating whether qemu has a bug for reporting 0 (it would be nicer if it always reserved 0 for not started, and non-zero for completed) - but how would we tell the difference between a fixed and broken qemu?