Hi
On Mon, May 17, 2021 at 11:11 AM Longpeng (Mike, Cloud Infrastructure Service Product Dept.) <
longpeng2@huawei.com> wrote:
We find a race during QEMU starting, which would case the QEMU process coredump.
<main loop> | <MON iothread>
|
[1] create MON chardev |
qemu_create_early_backends |
chardev_init_func |
|
[2] create MON iothread |
qemu_create_late_backends |
mon_init_func |
aio_bh_schedule-----------------------> monitor_qmp_setup_handlers_bh
[3] enter main loog | tcp_chr_update_read_handler
(* A client come in, e.g. Libvirt *) | update_ioc_handlers
tcp_chr_new_client |
update_ioc_handlers |
|
[4] create new hup_source |
s->hup_source = *PTR1* |
g_source_attach(s->hup_source)|
| [5] remove_hup_source(*PTR1*)
| (create new hup_source)
| s->hup_source = *PTR2*
[6] g_source_attach_unlocked |
*PTR1* is freed by [5] |
Do you have any suggestion to fix this bug ? Thanks!
I see.. I think the simplest would be for the chardev to not be dispatched in the original thread after monitor_init_qmp(). It looks like this should translate at least to calling qio_net_listener_set_client_func_full() with NULL handlers. I can't see where we could fit that in the chardev API. Perhaps add a new qemu_chr_be_disable_handlers() (until update_read_handlers is called again to enable them)?
Daniel? Paolo?
--
Marc-André Lureau