All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: John Snow <jsnow@redhat.com>, qemu-devel <qemu-devel@nongnu.org>,
	wangxiaolong@ucloud.cn
Subject: Re: [Qemu-devel] Fwd: qemu drive mirror assert fault
Date: Tue, 5 May 2015 15:36:09 +0800	[thread overview]
Message-ID: <20150505073609.GA9322@ad.nay.redhat.com> (raw)
In-Reply-To: <55424F3C.1050209@redhat.com>

On Thu, 04/30 17:50, Paolo Bonzini wrote:
> John, Fam,
> 
> I got this report offlist.  This happens if a bit in the hbitmap is
> cleared and the HBitmap has _not_ yet reached the bit.  See this comment
> in include/qemu/hbitmap.h:
> 
>  * Resetting bits before the current
>  * position of the iterator is also okay.  However, concurrent
>  * resetting of bits can lead to unexpected behavior if the iterator
>  * has not yet reached those bits.
> 
> Can you please take a look?

Since the gdb output is suggesting 1.5.3, it's worth to trying 2.3 which has
this:

    commit c4237dfa635900e4d1cdc6038d5efe3507f45f0c
    Author: Vladimir Sementsov-Ogievskiy <vsementsov@parallels.com>
    Date:   Thu Nov 27 12:40:46 2014 +0300

        block: fix spoiling all dirty bitmaps by mirror and migration

        Mirror and migration use dirty bitmaps for their purposes, and since
        commit [block: per caller dirty bitmap] they use their own bitmaps, not
        the global one. But they use old functions bdrv_set_dirty and
        bdrv_reset_dirty, which change all dirty bitmaps.

        Named dirty bitmaps series by Fam and Snow are affected: mirroring and
        migration will spoil all (not related to this mirroring or migration)
        named dirty bitmaps.

        This patch fixes this by adding bdrv_set_dirty_bitmap and
        bdrv_reset_dirty_bitmap, which change concrete bitmap. Also, to prevent
        such mistakes in future, old functions bdrv_(set,reset)_dirty are made
        static, for internal block usage.

        Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@parallels.com>
        CC: John Snow <jsnow@redhat.com>
        CC: Fam Zheng <famz@redhat.com>
        CC: Denis V. Lunev <den@openvz.org>
        CC: Stefan Hajnoczi <stefanha@redhat.com>
        CC: Kevin Wolf <kwolf@redhat.com>
        Reviewed-by: John Snow <jsnow@redhat.com>
        Reviewed-by: Fam Zheng <famz@redhat.com>
        Message-id: 1417081246-3593-1-git-send-email-vsementsov@parallels.com
        Signed-off-by: Max Reitz <mreitz@redhat.com>

Fam

> 
> Thanks,
> 
> Paolo
> 
> -------- Forwarded Message --------
> Subject: 	qemu drive mirror assert fault
> Date: 	Wed, 29 Apr 2015 10:50:28 +0800
> From: 	wangxiaolong <wangxiaolong@ucloud.cn>
> To: 	pbonzini <pbonzini@redhat.com>
> 
> hello,
> 
> I used drive mirror to do live migration, and I run into such an assert
> fault:
> 
> (gdb) bt
> 
> #0  0x00007fd2c6e678a5 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 
> #1  0x00007fd2c6e69085 in abort () at abort.c:92
> 
> #2  0x00007fd2c6e60a1e in __assert_fail_base (fmt=<value optimized out>,
> assertion=0x7fd2ca215aa0 "cur", file=0x7fd2ca215a78 "util/hbitmap.c",
> line=<value optimized out>,
> 
>     function=<value optimized out>) at assert.c:96
> 
> #3  0x00007fd2c6e60ae0 in __assert_fail (assertion=0x7fd2ca215aa0 "cur",
> file=0x7fd2ca215a78 "util/hbitmap.c", line=129, function=0x7fd2ca215bf0
> "hbitmap_iter_skip_words")
> 
>     at assert.c:105
> 
> #4  0x00007fd2ca1b3bb8 in hbitmap_iter_skip_words (hbi=<value optimized
> out>) at util/hbitmap.c:129
> 
> #5  0x00007fd2c9f8f8e0 in hbitmap_iter_next (opaque=0x7fd2cc59c730) at
> /usr/src/debug/qemu-kvm-1.5.3/include/qemu/hbitmap.h:166
> 
> #6  mirror_iteration (opaque=0x7fd2cc59c730) at block/mirror.c:163
> 
> #7  mirror_run (opaque=0x7fd2cc59c730) at block/mirror.c:407
> 
> #8  0x00007fd2c9fc45bb in coroutine_trampoline (i0=<value optimized
> out>, i1=<value optimized out>) at coroutine-ucontext.c:118
> 
> #9  0x00007fd2c6e78b70 in ?? () from /lib64/libc-2.12.so
> 
> #10 0x00007fff53eede80 in ?? ()
> 
> #11 0x0000000000000000 in ?? ()
> 
> 
> and I just can’t figure out what is the cause of this situation,
> could you help me figure it out, thanks!
> 
> 
> 
> 

  parent reply	other threads:[~2015-05-05  7:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <tencent_D4C0F8C0FE9E16802F5FF410@qq.com>
2015-04-30 15:50 ` [Qemu-devel] Fwd: qemu drive mirror assert fault Paolo Bonzini
2015-04-30 15:54   ` Paolo Bonzini
2015-05-05  7:36   ` Fam Zheng [this message]
2015-05-05 10:13     ` Paolo Bonzini
2015-05-05 10:27       ` Fam Zheng
2015-05-05 11:48         ` Kevin Wolf
2015-05-05 11:49           ` Paolo Bonzini
2015-05-05 11:54             ` Paolo Bonzini
2015-05-05 13:03             ` Kevin Wolf
2015-05-05 13:07               ` Paolo Bonzini
2015-05-05 13:31                 ` Kevin Wolf
2015-05-05 12:09           ` Fam Zheng

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=20150505073609.GA9322@ad.nay.redhat.com \
    --to=famz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wangxiaolong@ucloud.cn \
    /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.