The normal bdrv_co_pwritev() use is either
  - BDRV_REQ_ZERO_WRITE clear and iovector provided
  - BDRV_REQ_ZERO_WRITE set and iovector == NULL

while
  - the flag clear and iovector == NULL is an assertion failure
    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.

Currently, general functions like bdrv_rw_co() do provide iovector
regardless of flags. So, keep it supported and use bdrv_co_do_zero_pwritev()
alignment for it which also makes the code a bit more obvious anyway.

Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
---
 block/io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/io.c b/block/io.c
index 89d0745..40df3be 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);
         goto out;
     }
-- 
2.7.4

On Mon 12 Feb 2018 02:14:01 PM CET, Anton Nefedov wrote:
> The normal bdrv_co_pwritev() use is either
>   - BDRV_REQ_ZERO_WRITE clear and iovector provided
>   - BDRV_REQ_ZERO_WRITE set and iovector == NULL
>
> while
>   - the flag clear and iovector == NULL is an assertion failure
>     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.

Oh, so this doesn't simply write zeroes in [offset, offset+bytes), but
also in the head and tail areas, instead of keeping the previous
contents.

This is a pretty serious bug, but I assume it can't be triggered
(bdrv_pwrite_zeroes() is used in complete clusters). Did you check if
there was any other scenario where this could happen?

> Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>

Reviewed-by: Alberto Garcia <berto@igalia.com>

Berto

On 12/2/2018 6:03 PM, Alberto Garcia wrote:
> On Mon 12 Feb 2018 02:14:01 PM CET, Anton Nefedov wrote:
>> The normal bdrv_co_pwritev() use is either
>>    - BDRV_REQ_ZERO_WRITE clear and iovector provided
>>    - BDRV_REQ_ZERO_WRITE set and iovector == NULL
>>
>> while
>>    - the flag clear and iovector == NULL is an assertion failure
>>      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.
> 
> Oh, so this doesn't simply write zeroes in [offset, offset+bytes), but
> also in the head and tail areas, instead of keeping the previous
> contents.
> 
> This is a pretty serious bug, but I assume it can't be triggered
> (bdrv_pwrite_zeroes() is used in complete clusters). Did you check if
> there was any other scenario where this could happen?
> 

I was a bit lazy to look deep but as far as I can say currently it's
only bdrv_pwrite_zeroes(). It's mostly called for large extents like
clusters, but not everywhere, another case is I guess
qcow2_crypto_hdr_init_func(); also it's probably not guaranteed (though
being quite exotic) that the cluster size is not smaller than the
protocol driver alignment requirements.

At least external (block.h) write interfaces don't accept or set any
flags