| Message ID | 1454695953-14710-1-git-send-email-jsnow@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 02/05/2016 11:12 AM, John Snow wrote: > Commit 16b0d555 introduced an issue where we are not initializing > has_filename for the 'next' MapEntry object, which leads to interesting > errors in Valgrind and Clang -fsanitize=undefined both. grammar: errors in both Valgrind and Clang -fsanitize=undefined. > > Zero the stack object at allocation AND make sure the utility to > populate the fields properly marks has_filename as false if applicable. > > Signed-off-by: John Snow <jsnow@redhat.com> > --- > v2: Initialize with a compound literal as a future-proofing measure. > Reviewed-by: Eric Blake <eblake@redhat.com>
Am 05.02.2016 um 20:56 hat Eric Blake geschrieben: > On 02/05/2016 11:12 AM, John Snow wrote: > > Commit 16b0d555 introduced an issue where we are not initializing > > has_filename for the 'next' MapEntry object, which leads to interesting > > errors in Valgrind and Clang -fsanitize=undefined both. > > grammar: > > errors in both Valgrind and Clang -fsanitize=undefined. Fixed up. > > > > Zero the stack object at allocation AND make sure the utility to > > populate the fields properly marks has_filename as false if applicable. > > > > Signed-off-by: John Snow <jsnow@redhat.com> > > --- > > v2: Initialize with a compound literal as a future-proofing measure. > > > > Reviewed-by: Eric Blake <eblake@redhat.com> Thanks, applied to the block branch. Kevin
diff --git a/qemu-img.c b/qemu-img.c index f121980..4617d3b 100644 --- a/qemu-img.c +++ b/qemu-img.c @@ -2195,6 +2195,7 @@ static int get_block_status(BlockDriverState *bs, int64_t sector_num, int64_t ret; int depth; BlockDriverState *file; + bool has_offset; /* As an optimization, we could cache the current range of unallocated * clusters in each file of the chain, and avoid querying the same @@ -2221,17 +2222,20 @@ static int get_block_status(BlockDriverState *bs, int64_t sector_num, depth++; } - e->start = sector_num * BDRV_SECTOR_SIZE; - e->length = nb_sectors * BDRV_SECTOR_SIZE; - e->data = !!(ret & BDRV_BLOCK_DATA); - e->zero = !!(ret & BDRV_BLOCK_ZERO); - e->offset = ret & BDRV_BLOCK_OFFSET_MASK; - e->has_offset = !!(ret & BDRV_BLOCK_OFFSET_VALID); - e->depth = depth; - if (file && e->has_offset) { - e->has_filename = true; - e->filename = file->filename; - } + has_offset = !!(ret & BDRV_BLOCK_OFFSET_VALID); + + *e = (MapEntry) { + .start = sector_num * BDRV_SECTOR_SIZE, + .length = nb_sectors * BDRV_SECTOR_SIZE, + .data = !!(ret & BDRV_BLOCK_DATA), + .zero = !!(ret & BDRV_BLOCK_ZERO), + .offset = ret & BDRV_BLOCK_OFFSET_MASK, + .has_offset = has_offset, + .depth = depth, + .has_filename = file && has_offset, + .filename = file && has_offset ? file->filename : NULL, + }; + return 0; }
Commit 16b0d555 introduced an issue where we are not initializing has_filename for the 'next' MapEntry object, which leads to interesting errors in Valgrind and Clang -fsanitize=undefined both. Zero the stack object at allocation AND make sure the utility to populate the fields properly marks has_filename as false if applicable. Signed-off-by: John Snow <jsnow@redhat.com> --- v2: Initialize with a compound literal as a future-proofing measure. qemu-img.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-)