Re: [PULL 00/17] NBD patches through 2021-03-09

[Eric Blake]

On 3/11/21 1:02 PM, Peter Maydell wrote:
> On Tue, 9 Mar 2021 at 16:23, Eric Blake <eblake@redhat.com> wrote:
>>
>> The following changes since commit 0436c55edf6b357ff56e2a5bf688df8636f83456:
>>
>>   Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' 
>> into staging (2021-03-08 13:51:41 +0000)
>>
>> are available in the Git repository at:
>>
>>   https://repo.or.cz/qemu/ericb.git tags/pull-nbd-2021-03-09
>>
>> for you to fetch changes up to 1184b411016bce7590723170aa6b5984518707ec:
>>
>>   block/qcow2: refactor qcow2_update_options_prepare error paths (2021-03-08 
>> 16:04:46 -0600)
>>
>> ----------------------------------------------------------------
>> nbd patches for 2021-03-09
>>
>> - Add Vladimir as NBD co-maintainer
>> - Fix reporting of holes in NBD_CMD_BLOCK_STATUS
>> - Improve command-line parsing accuracy of large numbers (anything going
>> through qemu_strtosz), including the deprecation of hex+suffix
>> - Improve some error reporting in the block layer
>>
>> ----------------------------------------------------------------
> 
> This broke the gitlab cross-i386-user job:
> https://gitlab.com/qemu-project/qemu/-/jobs/1090685134
> 
> ERROR:../tests/test-cutils.c:2290:test_qemu_strtosz_metric: assertion
> failed (res == 12345000): (12344999 == 12345000)

Sounds like a floating point rounding error: the string was 12.345M, but
0.345 is not an exactly-representable double (the closest 32-bit IEEE
754 float is 0.3449999988079071044921875, while nextafter() gives
0.34500002861).  Multiplying that value by 1000000.0 can then round down
in some situations instead of producing the desired 345000.0.  The
rounding is less obvious with 64-bit doubles.  I'm not sure why
cross-i386-user seems to be prone to the rounding errors while other
builds are not.

> 
> Could you have a look, please?

Yes, I'll propose a followup patch soon.  Easiest would be to relax the
test to allow the imprecision, nicer would be tweaking qemu_strtosz() to
add in a fudge factor (probably based on DBL_EPSILON from <float.h>) to
let any multiplication errors tend to overshoot rather than undershoot
when close to an integer value.

> 
> (It's in master anyway, because at the time gitlab CI was lagging
> massively and I wasn't waiting around for it to finish before merging.)
> 
> thanks
> -- PMM
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org