Re: [Qemu-devel] Is blk_getlength() in find_image_format() and img_map() kosher?

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On 08/04/2017 08:55 AM, Markus Armbruster wrote:
> Have a look at find_image_format():
> 
>     if (blk_is_sg(file) || !blk_is_inserted(file) || blk_getlength(file) == 0) {
>         *pdrv = &bdrv_raw;
>         return ret;
>     }
> 
> blk_getlength() can fail.  Shouldn't we error out then?
> 
> We pretty obviously should in img_map():
> 
>     length = blk_getlength(blk);
>     while (curr.start + curr.length < length) {
> 
> Since I have to touch @length in the series I'm working on, I'll stick
> in a fix.

/me goes and checks my byte-based block status series

Hmm, that problem is still present even after my refactoring of
img_map().  I can rebase my series on top of your fix, as your fix
belongs in 2.10.

Alternatively, WHY do we allow blk_getlength() to fail?  Are there
really situations where we can open a BDS but not know its length?  I
know that we allow for online resizing detection, but presumably, either
we always know the (prior) size of the device, or we're going to have
problems talking to the device for anything beyond just a size request.
What semantics would change if we could guarantee that blk_getlength()
never failed?

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]