On 3/29/19 3:30 PM, Eric Blake wrote: >> ... yet the 2^63-512 image can be opened (same as before): >> >> $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd' >> image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket >> file format: raw >> virtual size: -8388607T (9223372036854775296 bytes) >> disk size: unavailable >> >> I've just noticed that the virtual size negative (also in upstream >> qemu). That looks like a bug too ... > > Yes, it does. I'll see if I can find a quick fix for that formatting > routine. >
qemu-img is calling block/qapi.c:get_human_readable_size(), which stops
at T, and has indeed has some horrible overflow problems, such as:
((size + (base >> 1)) / base),
without regards to whether int64_t size is near maximum before the addition.
Other places in the code base use util/cutils.c:size_to_str(), which
handles all the way up to E, and appears to be a bit saner.
Why we have to separate integer-to-human converters, where one is rather
buggy, is beyond me.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
