Hi On Mon, May 17, 2021 at 11:11 AM Longpeng (Mike, Cloud Infrastructure Service Product Dept.) <longpe...@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
