qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] Is blk_getlength() in find_image_format()


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] Is blk_getlength() in find_image_format() and img_map() kosher?
Date: Fri, 4 Aug 2017 10:39:24 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]