All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: famz@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] qemu-img: initialize MapEntry object
Date: Thu, 4 Feb 2016 10:52:59 -0500	[thread overview]
Message-ID: <56B373DB.40209@redhat.com> (raw)
In-Reply-To: <20160204124333.GB2314@noname>



On 02/04/2016 07:43 AM, Kevin Wolf wrote:
> Am 04.02.2016 um 00:38 hat John Snow geschrieben:
>> 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>
>> ---
>>  qemu-img.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/qemu-img.c b/qemu-img.c
>> index f121980..5a85178 100644
>> --- a/qemu-img.c
>> +++ b/qemu-img.c
>> @@ -2231,6 +2231,9 @@ static int get_block_status(BlockDriverState *bs, int64_t sector_num,
>>      if (file && e->has_offset) {
>>          e->has_filename = true;
>>          e->filename = file->filename;
>> +    } else {
>> +        e->has_filename = false;
>> +        e->filename = NULL;
>>      }
>>      return 0;
>>  }
> 
> I guess this fixes the bug, but wouldn't it actually be nicer to just
> reinitialise the whole object? As everyone knows, I love compound
> literals, so I'd make it one big assignment that zeroes everything that
> isn't specified:
> 
> *e = (MapEntry) {
>     ...
> };
> 

Yeah, that's more future proof isn't it.

>> @@ -2264,7 +2267,7 @@ static int img_map(int argc, char **argv)
>>      BlockDriverState *bs;
>>      const char *filename, *fmt, *output;
>>      int64_t length;
>> -    MapEntry curr = { .length = 0 }, next;
>> +    MapEntry curr = { .length = 0 }, next = { .length = 0 };
>>      int ret = 0;
> 
> At first I didn't quite understand what this was for, but I think you
> tried to cover newly added fields. If you overwrite the whole struct
> above, you wouldn't need to initialise it here any more.
> 
> Kevin
> 

Yeah, the intent was:

(1) Always make sure it starts out zeroed.
(2) In case someone tries to call get_block_status with an object that
isn't zeroed in the future, make sure has_filename is toggled back to false.



I'll send you a new one.

      reply	other threads:[~2016-02-04 15:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 23:38 [Qemu-devel] [PATCH] qemu-img: initialize MapEntry object John Snow
2016-02-04  1:38 ` Fam Zheng
2016-02-04 12:43 ` Kevin Wolf
2016-02-04 15:52   ` John Snow [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56B373DB.40209@redhat.com \
    --to=jsnow@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.