All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: arei.gonglei@huawei.com
Cc: ChenLiang <chenliang88@huawei.com>,
	weidong.huang@huawei.com, quintela@redhat.com,
	qemu-devel@nongnu.org, dgilbert@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v5 07/10] xbzrle: don't check the value in the vm ram repeatedly
Date: Fri, 4 Apr 2014 20:50:50 +0100	[thread overview]
Message-ID: <20140404195049.GA2492@work-vm> (raw)
In-Reply-To: <1396605482-8720-8-git-send-email-arei.gonglei@huawei.com>

* arei.gonglei@huawei.com (arei.gonglei@huawei.com) wrote:
> From: ChenLiang <chenliang88@huawei.com>
> 
> xbzrle_encode_buffer checks the value in the vm ram repeatedly.
> It is risk if runs xbzrle_encode_buffer on changing data.
> And it is not necessary.
> 
> Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Signed-off-by: ChenLiang <chenliang88@huawei.com>
> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
> ---
>  xbzrle.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/xbzrle.c b/xbzrle.c
> index fbcb35d..92cccd7 100644
> --- a/xbzrle.c
> +++ b/xbzrle.c
> @@ -27,9 +27,10 @@ int xbzrle_encode_buffer(uint8_t *old_buf, uint8_t *new_buf, int slen,
>                           uint8_t *dst, int dlen)
>  {
>      uint32_t zrun_len = 0, nzrun_len = 0;
> -    int d = 0, i = 0;
> +    int d = 0, i = 0, j;
>      long res, xor;
>      uint8_t *nzrun_start = NULL;
> +    uint8_t *xor_ptr = (uint8_t *)(&xor);
>  
>      g_assert(!(((uintptr_t)old_buf | (uintptr_t)new_buf | slen) %
>                 sizeof(long)));
> @@ -82,6 +83,8 @@ int xbzrle_encode_buffer(uint8_t *old_buf, uint8_t *new_buf, int slen,
>          if (d + 2 > dlen) {
>              return -1;
>          }
> +        i++;
> +        nzrun_len++;

Yes, I think that's safe - I was checking for if an overflow was possible, but
my reading is that before this 'i++' i can be a maximum of slen-1, so here
it's a maximum of slen and the next loop won't happen in that case.

>          /* not aligned to sizeof(long) */
>          res = (slen - i) % sizeof(long);
>          while (res && old_buf[i] != new_buf[i]) {
> @@ -98,11 +101,16 @@ int xbzrle_encode_buffer(uint8_t *old_buf, uint8_t *new_buf, int slen,
>                  xor = *(long *)(old_buf + i) ^ *(long *)(new_buf + i);
>                  if ((xor - mask) & ~xor & (mask << 7)) {
>                      /* found the end of an nzrun within the current long */
> -                    while (old_buf[i] != new_buf[i]) {
> -                        nzrun_len++;
> -                        i++;
> +                    for (j = 0; j < sizeof(long); j++) {
> +                        if (0 == xor_ptr[j]) {
> +                            break;
> +                        }
> +                    }
> +                    i += j;
> +                    nzrun_len += j;

> +                    if (j != sizeof(long)) {
> +                        break;
>                      }
> -                    break;
>                  } else {
>                      i += sizeof(long);
>                      nzrun_len += sizeof(long);
> @@ -118,6 +126,8 @@ int xbzrle_encode_buffer(uint8_t *old_buf, uint8_t *new_buf, int slen,
>          memcpy(dst + d, nzrun_start, nzrun_len);
>          d += nzrun_len;
>          nzrun_len = 0;
> +        i++;
> +        zrun_len++;

I think that's also safe, because if i was now 'slen' the mainloop would exit, that would
mean the last zero run wasn't encoded, but there seems to already be a check that causes
the last zero run not to be encoded.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

>      }
>  
>      return d;
> -- 
> 1.7.12.4
> 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2014-04-04 19:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-04  9:57 [Qemu-devel] [PATCH v5 00/10] migration: Optimizate the xbzrle and fix one corruption issue arei.gonglei
2014-04-04  9:57 ` [Qemu-devel] [PATCH v5 01/10] XBZRLE: Fix one XBZRLE corruption issues arei.gonglei
2014-04-04  9:57 ` [Qemu-devel] [PATCH v5 02/10] migration: Add counts of updating the dirty bitmap arei.gonglei
2014-04-04  9:57 ` [Qemu-devel] [PATCH v5 03/10] migration: expose the bitmap_sync_count to the end arei.gonglei
2014-04-04  9:57 ` [Qemu-devel] [PATCH v5 04/10] migration: expose xbzrle cache miss rate arei.gonglei
2014-04-04  9:57 ` [Qemu-devel] [PATCH v5 05/10] XBZRLE: optimize XBZRLE to decrease the cache misses arei.gonglei
2014-05-01 14:24   ` Eric Blake
2014-04-04  9:57 ` [Qemu-devel] [PATCH v5 06/10] XBZRLE: rebuild the cache_is_cached function arei.gonglei
2014-05-01 14:29   ` Eric Blake
2014-04-04  9:57 ` [Qemu-devel] [PATCH v5 07/10] xbzrle: don't check the value in the vm ram repeatedly arei.gonglei
2014-04-04 19:50   ` Dr. David Alan Gilbert [this message]
2014-04-04  9:58 ` [Qemu-devel] [PATCH v5 08/10] xbzrle: check 8 bytes at a time after an concurrency scene arei.gonglei
2014-04-04 19:52   ` Dr. David Alan Gilbert
2014-04-05  2:39     ` 陈梁
2014-04-04  9:58 ` [Qemu-devel] [PATCH v5 09/10] migration: optimize xbzrle by reducing data copy arei.gonglei
2014-04-04 19:59   ` Dr. David Alan Gilbert
2014-04-04  9:58 ` [Qemu-devel] [PATCH v5 10/10] migration: clear the dead code arei.gonglei
2014-04-04 17:16 ` [Qemu-devel] [PATCH v5 00/10] migration: Optimizate the xbzrle and fix one corruption issue Dr. David Alan Gilbert
2014-04-04 17:24 ` [Qemu-devel] For 2.0? " Eric Blake
2014-04-04 17:40   ` Dr. David Alan Gilbert

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=20140404195049.GA2492@work-vm \
    --to=dgilbert@redhat.com \
    --cc=arei.gonglei@huawei.com \
    --cc=chenliang88@huawei.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=weidong.huang@huawei.com \
    /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.