qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, "Laurent Vivier" <lvivier@redhat.com>,
	"Fam Zheng" <famz@redhat.com>,
	"Juan Quintela" <quintela@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	mdroth@linux.vnet.ibm.com,
	"Stefan Hajnoczi" <shajnocz@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [RFC 07/15] monitor: unify global init
Date: Wed, 20 Sep 2017 14:54:34 +0800	[thread overview]
Message-ID: <20170920065434.GW3617@pxdev.xzpeter.org> (raw)
In-Reply-To: <dd2bfb4d-2899-fad1-00a0-ffb833588618@redhat.com>

On Tue, Sep 19, 2017 at 04:48:35PM -0500, Eric Blake wrote:
> On 09/19/2017 04:35 PM, Eric Blake wrote:
> > On 09/14/2017 02:50 AM, Peter Xu wrote:
> >> There are many places for monitor init its globals, at least:
> >>
> 
> > Are we sure that this new function is called sooner than any access to
> > monitor_lock,
> > 
> >> -static void __attribute__((constructor)) monitor_lock_init(void)
> >> -{
> >> -    qemu_mutex_init(&monitor_lock);
> >> -}
> > 
> > especially since the old code initialized the lock REALLY early?
> 
> (Partially) answering myself:
> 
> > 
> > Pre-patch, a breakpoint on main() and on monitor_lock_init() fires on
> > monitor_lock_init() first, prior to main.
> > 
> > Breakpoint 2, monitor_lock_init () at /home/eblake/qemu/monitor.c:4089
> > 4089	    qemu_mutex_init(&monitor_lock);
> > (gdb) c
> > Continuing.
> > [New Thread 0x7fffce225700 (LWP 26380)]
> > 
> > Thread 1 "qemu-system-x86" hit Breakpoint 1, main (argc=5,
> >     argv=0x7fffffffdc88, envp=0x7fffffffdcb8) at vl.c:3077
> > 3077	{
> 
> Also, pre-patch, 'watch monitor_lock.initialized' and 'watch
> monitor_lock.lock.__data.__lock' show that the lock is first utilized at:
> 
> (gdb) bt
> #0  0x00007fffdac59e12 in __GI___pthread_mutex_lock
> (mutex=0x555556399340 <monitor_lock>) at ../nptl/pthread_mutex_lock.c:80
> #1  0x0000555555ce01ed in qemu_mutex_lock (mutex=0x555556399340
> <monitor_lock>)
>     at util/qemu-thread-posix.c:65
> #2  0x00005555557bc8b8 in monitor_init (chr=0x55555690bf70, flags=4)
>     at /home/eblake/qemu/monitor.c:4126
> #3  0x000055555591ae80 in mon_init_func (opaque=0x0,
> opts=0x55555688e3d0, errp=0x0) at vl.c:2482
> #4  0x0000555555cf3e63 in qemu_opts_foreach (list=0x555556225200
> <qemu_mon_opts>, func=0x55555591ad33 <mon_init_func>, opaque=0x0, errp=0x0)
>     at util/qemu-option.c:1104
> #5  0x0000555555920128 in main (argc=5, argv=0x7fffffffdc88,
> envp=0x7fffffffdcb8) at vl.c:4670
> 
> and double-checking qemu_mutex_lock, our .initialized member provides
> NICE runtime checking that we don't use an uninitialized lock.  So the
> fact that your patch doesn't assert means your later initialization is
> still fine.

Yeah, that's something I liked as well.

> 
> [TIL: the gdb 'watch' command is cool, but it's better if you watch only
> 4 or 8 bytes at a time; I first tried 'watch monitor_lock', but that's
> hundreds of times slower as hardware can't watch that much data at once,
> at which point gdb emulates it by single-stepping the entire program]

Good to learn it!

Thanks for digging the whole thing up.

> 
> > 
> > Post-patch, the mutex is not initialized until well after main().  So
> > the real question is what (if anything) is using the lock in between
> > those two points?
> 
> According to gdb watchpoints, no.
> 
> > 
> > Hmm - it may be that we needed it back before commit 05875687, when we
> > really did depend on MODULE_INIT_QAPI, but it is something we forgot to
> > cleanup in the meantime?
> 
> So what I didn't debug was whether the constructor attribute was
> mandatory in the past, and if so, which commit made it no longer
> mandatory (my mention of commit 05875687 is only a guess).
> 
> > 
> > If nothing else, the commit message should call out that dropping
> > __attribute__((constructor)) nonsense is intentional (if it was indeed
> > nonsense).
> > 
> 
> This part is still true.

If this patch is doable, I'll add explicit reason to commit message.

Paolo/Markus, would any of you help confirm this change? (considering
Paolo introduced commit d622cb587)

One thing I slightly not sure of is that, some device realization has
this code path (take fsl_imx25_realize() as example):

  fsl_imx25_realize
    qemu_chr_new
      qemu_chr_new_noreplay
        char is_mux?
          monitor_init

(note: I never know why we create the monitor in chardev
 creation... would there be a better place?)

Especially considering some integrated devices can be created along
with machine init.

Anyway, this patch was trying to cleanup the things a bit, and also
more convenient for me to add new codes upon.  If any of us think it's
not safe enough, please say explicitly, and I can drop it and do the
rest in "the ugly way".

Thanks,

-- 
Peter Xu

  reply	other threads:[~2017-09-20  6:54 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-14  7:50 [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 01/15] char-io: fix possible race on IOWatchPoll Peter Xu
2017-09-19 19:59   ` Eric Blake
2017-09-20  4:44     ` Peter Xu
2017-09-20  7:57   ` Daniel P. Berrange
2017-09-20  9:09     ` Peter Xu
2017-09-20  9:14       ` Daniel P. Berrange
2017-09-20 10:49         ` Peter Xu
2017-09-20 11:03           ` Daniel P. Berrange
2017-09-20 11:18             ` Peter Xu
2017-09-20 11:29               ` Daniel P. Berrange
2017-09-21  3:45                 ` Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 02/15] qobject: allow NULL for qstring_get_str() Peter Xu
2017-09-19 20:48   ` Eric Blake
2017-09-20  5:02     ` Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 03/15] qobject: introduce qobject_to_str() Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 04/15] monitor: move skip_flush into monitor_data_init Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 05/15] qjson: add "opaque" field to JSONMessageParser Peter Xu
2017-09-19 20:55   ` Eric Blake
2017-09-20  5:45     ` Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 06/15] monitor: move the cur_mon hack deeper for QMP Peter Xu
2017-09-19 21:05   ` Eric Blake
2017-09-20  5:54     ` Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 07/15] monitor: unify global init Peter Xu
2017-09-19 21:35   ` Eric Blake
2017-09-19 21:48     ` Eric Blake
2017-09-20  6:54       ` Peter Xu [this message]
2017-09-14  7:50 ` [Qemu-devel] [RFC 08/15] monitor: create IO thread Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 09/15] monitor: allow to use IO thread for parsing Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 10/15] monitor: introduce monitor_qmp_respond() Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 11/15] monitor: separate QMP parser and dispatcher Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 12/15] monitor: enable IO thread for (qmp & !mux) typed Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 13/15] qapi: introduce new cmd option "allow-oob" Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 14/15] qmp: support out-of-band (oob) execution Peter Xu
2017-09-14 15:33   ` Stefan Hajnoczi
2017-09-15  2:59     ` Peter Xu
2017-09-15 18:34       ` Eric Blake
2017-09-18  7:36         ` Peter Xu
2017-09-15 15:55   ` Dr. David Alan Gilbert
2017-09-18  7:53     ` Peter Xu
2017-09-14  7:50 ` [Qemu-devel] [RFC 15/15] qmp: let migrate-incoming allow out-of-band Peter Xu
2017-09-15 16:09   ` Dr. David Alan Gilbert
2017-09-18  8:00     ` Peter Xu
2017-09-14 11:15 ` [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support Marc-André Lureau
2017-09-14 15:19   ` Stefan Hajnoczi
2017-09-15  3:50     ` Peter Xu
2017-09-15 10:49       ` Stefan Hajnoczi
2017-09-15 11:34         ` Daniel P. Berrange
2017-09-15 12:06           ` Dr. David Alan Gilbert
2017-09-15 12:14             ` Daniel P. Berrange
2017-09-15 12:19               ` Dr. David Alan Gilbert
2017-09-15 12:29                 ` Daniel P. Berrange
2017-09-15 14:29                   ` Dr. David Alan Gilbert
2017-09-15 14:32                     ` Daniel P. Berrange
2017-09-15 14:56                   ` Stefan Hajnoczi
2017-09-15 15:17                     ` Dr. David Alan Gilbert
2017-09-18  9:26                       ` Peter Xu
2017-09-18 10:40                         ` Dr. David Alan Gilbert
2017-09-19  2:23                           ` Peter Xu
2017-09-19  9:13                             ` Dr. David Alan Gilbert
2017-09-19  9:22                               ` Peter Xu
2017-09-14 18:53   ` Dr. David Alan Gilbert
2017-09-15  4:46     ` Peter Xu
2017-09-15 11:14       ` Marc-André Lureau
2017-09-18  8:37         ` Peter Xu
2017-09-18 10:20           ` Marc-André Lureau
2017-09-18 10:55             ` Dr. David Alan Gilbert
2017-09-18 11:13               ` Marc-André Lureau
2017-09-18 11:26                 ` Dr. David Alan Gilbert
2017-09-18 16:09                   ` Marc-André Lureau
2017-09-19  6:29                     ` Peter Xu
2017-09-19  9:19                       ` Dr. David Alan Gilbert
2017-09-20  4:37                         ` Peter Xu
2017-09-19 18:49                     ` Dr. David Alan Gilbert
2017-09-18 15:08               ` Eric Blake
2017-09-14 18:56 ` Dr. David Alan Gilbert
2017-09-15  3:58   ` Peter Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170920065434.GW3617@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=shajnocz@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).