Re: [Qemu-devel] [PULL 6/7] monitor: move init global earlier

[Peter Xu <peterx@redhat.com>]

On Wed, Sep 05, 2018 at 05:05:10PM +0200, Wolfgang Bumiller wrote:
> On Mon, Jun 18, 2018 at 04:08:53PM +0200, Markus Armbruster wrote:
> > From: Peter Xu <peterx@redhat.com>
> > 
> > Before this patch, monitor fd helpers might be called even earlier than
> > monitor_init_globals().  This can be problematic.
> > 
> > After previous work, now monitor_init_globals() does not depend on
> > accelerator initialization any more.  Call it earlier (before CLI
> > parsing; that's where the monitor APIs might be called) to make sure it
> > is called before any of the monitor APIs.
> 
> It looks like this patch moves the creation of the 'IO mon_iothread' to
> before the call to os_daemonize().
> With qemu 3.0 I'm experiencing crashes when shutting down daemonized
> qemu instances, at pthread_join() on the 'IO mon_iothread' thread.
> 
> monitor_init_globals() calls monitor_iothread_init(), which in turn uses
> iothread_create() to create a joinable thread. Then os_daemonize() is
> called after which the thread is no longer "ours".
> Debug-writing the thread IDs at pthread_create() and pthread_join()
> together with the 'detachable' flag revealed that the mon_iothread ID is
> already being reused, in my trace for a detached thread, and the join
> then ends with a coredump and ugly log output.

Indeed.  So we have these ordering constraints:

  init mon locks [1]
  cli parsing
  daemonize
  create mon iothread [2]

I can't figure out a way unless we split the global init routine for
the monitors, possibly (and simply) by postpone creation of the
iothread.  Thoughts?

(Note that AFAICT Markus is on holiday and will be back after two weeks)

Regards,

-- 
Peter Xu