Am 19.07.2013 19:07, schrieb Paolo Bonzini:
> Il 19/07/2013 09:33, Stefan Hajnoczi ha scritto:
>> On Tue, Jul 16, 2013 at 06:29:28PM +0200, Paolo Bonzini wrote:
>>> diff --git a/block.c b/block.c
>>> index 557ce29..2d7d71f 100644
>>> --- a/block.c
>>> +++ b/block.c
>>> @@ -2977,7 +2977,7 @@ static int64_t coroutine_fn
>>> bdrv_co_get_block_status(BlockDriverState *bs,
>>> int nb_sectors, int
>>> *pnum)
>>> {
>>> int64_t n;
>>> - int64_t ret;
>>> + int64_t ret, ret2;
>>>
>>> if (sector_num >= bs->total_sectors) {
>>> *pnum = 0;
>>> @@ -3003,6 +3003,14 @@ static int64_t coroutine_fn
>>> bdrv_co_get_block_status(BlockDriverState *bs,
>>> ret |= BDRV_BLOCK_ZERO;
>>> }
>>>
>>> + if (bs->file &&
>>> + (ret & BDRV_BLOCK_DATA) && !(ret & BDRV_BLOCK_ZERO) &&
>>> + (ret & BDRV_BLOCK_OFFSET_VALID)) {
>>> + ret2 = bdrv_co_get_block_status(bs->file, ret >> BDRV_SECTOR_BITS,
>>> + *pnum, pnum);
>>> + ret |= (ret2 & BDRV_BLOCK_ZERO);
>>> + }
>> This patch breaks qemu-iotests 030 (image streaming).
>>
>> The problem is that bdrv_co_get_block_status() uses bs->total_sectors
>> directly instead of calling bdv_get_geometry()/bdrv_getlength().
>>
>> With qcow2 the bs->file can grow on disk. We don't update
>> bs->total_sectors.
>>
>> Then this patch calls bdrv_co_get_block_status(bs->file) where we fail
>> with *pnum = 0, ret = 0 because bs->total_sectors suggests it is beyond
>> the end of the file.
>>
>> The result is that 030 goes into an infinite loop.
>>
>> As a quick test I switched the direct bs->total_sectors accesses to
>> bdrv_get_geometry() and it stopped hanging. Perhaps the
>> bs->total_sectors caching needs to be improved though.
> Yes, fixing the caching also resolves the failure. I'll send a v3 next
> Monday or perhaps Sunday.
Do you have the v3 ready?
