On 4/1/19 8:16 AM, Daniel P. Berrangé wrote: > On Mon, Apr 01, 2019 at 03:04:16PM +0200, Kevin Wolf wrote: >> Am 30.03.2019 um 16:07 hat Eric Blake geschrieben: >>> Disk sizes close to INT64_MAX cause overflow, for some pretty >>> ridiculous output: >>> >>> $ ./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 >>>
>> This is quite obviously a bug fix for some cases. This suggests that we >> want it in 4.0. >> >> It is also an output change for other cases, like going from "8M" to >> "8 MiB". We probably can't tell for sure whether some tools expect the >> spelling "8M" (even if this is supposed to be the human interface and >> tools should be using JSON) or feed the change back to qemu-img or >> qemu-io (which accept "8M", but not "8 MiB" as sizes in most places). >> This suggests that we shouldn't make this change as late as -rc2. > > If it breaks our own tests, then it is possible to break other tools > too. > >> So what is the conclusion? > > The safe option is to do the minimal fix for the existing code and look at > the refactoring in the next dev cycle. It's not worth fixing the second implementation to match the first in terms of support for sizes > T with no overflow, but with the existing format of 8.0M vs. 8 MiB. I'm happy to defer this patch to 4.1; the bug is not new to 4.0, so living with it for one more release doesn't hurt. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
