[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 5/6] monitor: prevent inserting new monitors
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH v2 5/6] monitor: prevent inserting new monitors after cleanup |
Date: |
Mon, 03 Dec 2018 13:16:09 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Marc-André Lureau <address@hidden> writes:
> Hi
> On Mon, Dec 3, 2018 at 12:59 PM Markus Armbruster <address@hidden> wrote:
>>
>> Marc-André Lureau <address@hidden> writes:
>>
>> > Add a monitor_destroyed global to check if monitor_cleanup() has been
>> > already called. In this case, don't insert the new monitor in the
>> > list, but free it instead.
>> >
>> > Signed-off-by: Marc-André Lureau <address@hidden>
>>
>> The commit message explains what the patch does, but not why we want to
>> do it.
>>
>> > ---
>> > monitor.c | 14 ++++++++++++--
>> > 1 file changed, 12 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/monitor.c b/monitor.c
>> > index fffeb27ef9..7fe89daa87 100644
>> > --- a/monitor.c
>> > +++ b/monitor.c
>> > @@ -263,10 +263,11 @@ typedef struct QMPRequest QMPRequest;
>> > /* QMP checker flags */
>> > #define QMP_ACCEPT_UNKNOWNS 1
>> >
>> > -/* Protects mon_list, monitor_qapi_event_state. */
>> > +/* Protects mon_list, monitor_qapi_event_state, monitor_destroyed. */
>> > static QemuMutex monitor_lock;
>> > static GHashTable *monitor_qapi_event_state;
>> > static QTAILQ_HEAD(mon_list, Monitor) mon_list;
>> > +static bool monitor_destroyed;
>> >
>> > /* Protects mon_fdsets */
>> > static QemuMutex mon_fdsets_lock;
>> > @@ -4536,8 +4537,16 @@ void error_vprintf_unless_qmp(const char *fmt,
>> > va_list ap)
>> > static void monitor_list_append(Monitor *mon)
>> > {
>> > qemu_mutex_lock(&monitor_lock);
>> > - QTAILQ_INSERT_HEAD(&mon_list, mon, entry);
>> > + if (!monitor_destroyed) {
>> > + QTAILQ_INSERT_HEAD(&mon_list, mon, entry);
>> > + mon = NULL;
>> > + }
>> > qemu_mutex_unlock(&monitor_lock);
>> > +
>> > + if (mon) {
>> > + monitor_data_destroy(mon);
>> > + g_free(mon);
>> > + }
>> > }
>> >
>> > static void monitor_qmp_setup_handlers_bh(void *opaque)
>> > @@ -4631,6 +4640,7 @@ void monitor_cleanup(void)
>> >
>> > /* Flush output buffers and destroy monitors */
>> > qemu_mutex_lock(&monitor_lock);
>> > + monitor_destroyed = true;
>> > QTAILQ_FOREACH_SAFE(mon, &mon_list, entry, next) {
>> > QTAILQ_REMOVE(&mon_list, mon, entry);
>> > monitor_flush(mon);
>>
>> monitor_cleanup() is one of the last things main() calls before it
>> returns. If another thread creates a monitor afterwards, it won't be
>> cleaned up. I figure that's the reason we want this patch. There might
>> be more serious issues than failure to clean up. Please explain in your
>> commit message.
>
> Is this clearer?
>
> monitor_cleanup() is one of the last things main() calls before it
> returns. In the following patch, monitor_cleanup() will release the
> monitor_lock during flushing. There may be pending commands to insert
> new monitors, which would modify the mon_list during iteration, and
> the clean-up could thus miss those new insertions.
>
> Add a monitor_destroyed global to check if monitor_cleanup() has been
> already called. In this case, don't insert the new monitor in the
> list, but free it instead.
Yes.
The solution feels a bit clunky: it duplicates part of the work
monitor_cleanup() does into monitor_list_append(). Works because the
part it doesn't duplicate needn't be done in this case: removing from
@mon_list, and monitor_flush().
I suspect a cleaner solution would involve the main thread telling other
threads to terminate, waiting for their termination with pthread_join(),
and only then do final cleanup.
I'm not asking for that solution now. A clunky fix we have is better
than a refactoring we don't have. A comment admitting the clunkiness
would be nice.
>> monitor_list_append() is called by monitor_init(), either directly right
>> before it returns, or via a bottom half if mon->use_io_thread.
>> Therefore, @monitor_destroyed can only be true if monitor_init()
>> commonly runs in a thread other than the main thread. Please give an
>> example where it does, in your commit message.