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.
[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]
>
> 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.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
