[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A bug of Monitor Chardev ?
From: |
Daniel P . Berrangé |
Subject: |
Re: A bug of Monitor Chardev ? |
Date: |
Tue, 8 Jun 2021 16:37:11 +0100 |
User-agent: |
Mutt/2.0.7 (2021-05-04) |
On Tue, Jun 08, 2021 at 04:07:30PM +0200, Markus Armbruster wrote:
> "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)"
> <longpeng2@huawei.com> writes:
>
> > 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!
>
> Do we? We talked, but I'm not sure we reached a conclusion.
Seems like we ended up with two options.
1. A workaround for the current specific problem by rearranging
the initilization code in the monitor a little.
2. A design fix of splitting the chardev creation into two
parts, one creation, and one activation.
The latter is significantly more work, but is a better long term bet IMHO.
But what we really is someone motivated to actually implement one of the
two options.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|