All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hailiang Zhang <zhang.zhanghailiang@huawei.com>
To: Jason Wang <jasowang@redhat.com>, zhangchen.fnst@cn.fujitsu.com
Cc: xuquan8@huawei.com, qemu-devel@nongnu.org, weidong.huang@huawei.com
Subject: Re: [Qemu-devel] [PATCH 1/3] colo-compare: serialize compare thread's initialization with main thread
Date: Tue, 25 Apr 2017 17:59:19 +0800	[thread overview]
Message-ID: <58FF1DF7.4000006@huawei.com> (raw)
In-Reply-To: <82c50df3-28c9-fb21-f2c6-76a99f864bee@redhat.com>

On 2017/4/25 16:41, Jason Wang wrote:
>
> On 2017年04月24日 14:03, Hailiang Zhang wrote:
>> On 2017/4/24 12:10, Jason Wang wrote:
>>> On 2017年04月20日 15:46, zhanghailiang wrote:
>>>> We call qemu_chr_fe_set_handlers() in colo-compare thread, it is used
>>>> to detach watched fd from default main context, so it has chance to
>>>> handle the same watched fd with main thread concurrently, which will
>>>> trigger an error report:
>>>> "qemu-char.c:918: io_watch_poll_finalize: Assertion `iwp->src ==
>>>> ((void *)0)' failed."
>>> Anyway to prevent fd from being handled by main thread before creating
>>> colo thread? Using semaphore seems not elegant.
>> So how about calling qemu_mutex_lock_iothread() before
>> qemu_chr_fe_set_handlers() ?
> Looks better, but I needs more information e.g how main thread can touch it?

Hmm, this happened quite occasionally, and we didn't catch the first place (backtrace)
of removing fd from been watched, but  from the codes logic, we found there should
be such possible cases:
tcp_chr_write (Or tcp_chr_read/tcp_chr_sync_read/chr_disconnect)
  ->tcp_chr_disconnect (Or char_socket_finalize)
     ->tcp_chr_free_connection
       -> remove_fd_in_watch(chr);

Anyway, it needs the protection from been freed twice.

Thanks,
Hailiang
> Thanks
>
> .
>

  reply	other threads:[~2017-04-25 10:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-20  7:46 [Qemu-devel] [PATCH 0/3] colo-compare: fix three bugs zhanghailiang
2017-04-20  7:46 ` [Qemu-devel] [PATCH 1/3] colo-compare: serialize compare thread's initialization with main thread zhanghailiang
2017-04-24  4:10   ` Jason Wang
2017-04-24  6:03     ` Hailiang Zhang
2017-04-25  8:41       ` Jason Wang
2017-04-25  9:59         ` Hailiang Zhang [this message]
2017-04-25 11:33           ` Jason Wang
2017-04-26  7:51             ` Hailiang Zhang
2017-05-04  2:51             ` Hailiang Zhang
2017-05-05  3:03               ` Jason Wang
2017-04-20  7:46 ` [Qemu-devel] [PATCH 2/3] colo-compare: Check main_loop value before call g_main_loop_quit zhanghailiang
2017-04-24  4:13   ` Jason Wang
2017-04-24  6:06     ` Hailiang Zhang
2017-04-20  7:46 ` [Qemu-devel] [PATCH 3/3] colo-compare: fix a memory leak zhanghailiang

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=58FF1DF7.4000006@huawei.com \
    --to=zhang.zhanghailiang@huawei.com \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=weidong.huang@huawei.com \
    --cc=xuquan8@huawei.com \
    --cc=zhangchen.fnst@cn.fujitsu.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.