qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH] block: fix write with zero flag se


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH] block: fix write with zero flag set and iovector provided
Date: Thu, 1 Feb 2018 08:40:51 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 02/01/2018 08:36 AM, Eric Blake wrote:
> On 02/01/2018 08:16 AM, Anton Nefedov wrote:
>> The normal bdrv_co_pwritev() use is either
>>   - BDRV_REQ_ZERO_WRITE reset and iovector provided
> 
> s/reset/clear/
> 
>>   - BDRV_REQ_ZERO_WRITE set and iovector == NULL
>>
>> while
>>   - the flag reset and iovector == NULL is an assertion failure
> 
> again
> 
>>     in bdrv_co_do_zero_pwritev()
>>   - the flag set and iovector provided is in fact allowed
>>     (the flag prevails and zeroes are written)
>>
>> However the alignment logic does not support the latter case so the padding
>> areas get overwritten with zeroes.
>>
>> Solution could be to forbid such case or just use bdrv_co_do_zero_pwritev()
>> alignment for it which also makes the code a bit more obvious anyway.
>>
>> Signed-off-by: Anton Nefedov <address@hidden>
>> ---
>>  block/io.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/block/io.c b/block/io.c
>> index 7ea4023..cf63fd0 100644
>> --- a/block/io.c
>> +++ b/block/io.c
>> @@ -1701,7 +1701,7 @@ int coroutine_fn bdrv_co_pwritev(BdrvChild *child,
>>       */
>>      tracked_request_begin(&req, bs, offset, bytes, BDRV_TRACKED_WRITE);
>>  
>> -    if (!qiov) {
>> +    if (flags & BDRV_REQ_ZERO_WRITE) {
>>          ret = bdrv_co_do_zero_pwritev(child, offset, bytes, flags, &req);
> 
> So now, the flag rules, but we assert that !qiov (so it would only break
> a caller that passed the flag but used qiov, which you argued shouldn't
> exist).

Sorry, I hit send too soon.  I'm asking if we should have assert(!qiov)
right before calling bdrv_co_do_zero_pwritev (it would break a caller
that passed the flag and qiov, but you were arguing that such callers
previously misbehaved, so we don't want such callers).

But adding such an assertion may trigger failures that we'd have to fix,
while leaving things without the assertion conservatively seems okay.

> 
> Reviewed-by: Eric Blake <address@hidden>
> 

-- 
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]