Yes, my patch will break the thread safe implementation, just avoid the deadlock. This is the call trace when the dead lock happened.
#0 0x00007ffff27dbf79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff27df388 in __GI_abort () at abort.c:89 #2 0x00005555555ef489 in error_exit (err=<optimized out>, msg=msg@entry=0x5555559796d0 <__func__.5959> "qemu_mutex_lock") at util/qemu-thread-posix.c:47 #3 0x00005555558f9080 in qemu_mutex_lock (mutex=mutex@entry=0x555556248a30) at util/qemu-thread-posix.c:78 #4 0x0000555555713936 in qemu_chr_fe_write (s=0x555556248a30, buf=buf@entry=0x5555563d8870 "QEMU 2.0.90 monitor - type 'help' for more information\r\n", len=56) at qemu-char.c:127 #5 0x00005555556217fd in monitor_flush_locked (mon=mon@entry=0x555556251fd0) at /home/liliang/vt-sync/qemu/monitor.c:310 #6 0x0000555555621a12 in monitor_flush_locked (mon=0x555556251fd0) at /home/liliang/vt-sync/qemu/monitor.c:302 #7 monitor_puts (mon=mon@entry=0x555556251fd0, str=0x55555634bfa7 "", str@entry=0x55555634bf70 "QEMU 2.0.90 monitor - type 'help' for more information\n") at /home/liliang/vt-sync/qemu/monitor.c:352 #8 0x0000555555624359 in monitor_vprintf (mon=0x555556251fd0, fmt=<optimized out>, ap=<optimized out>) at /home/liliang/vt-sync/qemu/monitor.c:370 #9 0x0000555555624414 in monitor_printf (mon=<optimized out>, fmt=fmt@entry=0x5555559105a0 "QEMU %s monitor - type 'help' for more information\n") at /home/liliang/vt-sync/qemu/monitor.c:378 #10 0x0000555555629806 in monitor_event (opaque=0x555556251fd0, event=<optimized out>) at /home/liliang/vt-sync/qemu/monitor.c:5243 #11 0x000055555571343c in qemu_chr_be_generic_open (s=0x555556248a30) at qemu-char.c:120 #12 pty_chr_state (chr=chr@entry=0x555556248a30, connected=connected@entry=1) at qemu-char.c:1216 #13 0x00005555557134ee in pty_chr_update_read_handler_locked (chr=chr@entry=0x555556248a30) at qemu-char.c:1133 #14 0x00005555557135ab in pty_chr_timer (opaque=0x555556248a30) at qemu-char.c:1097 #15 0x00007ffff629d703 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x00007ffff629cce5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x00005555558ac888 in glib_pollfds_poll () at main-loop.c:190 #18 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:235 #19 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:484 #20 0x00005555555f153e in main_loop () at vl.c:2010 #21 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4530 It can be showed simply like bellow: ptr_char_timer () { qemu_mutex_lock(&chr->chr_write_lock); ... monitor_flush_locked() { ... qemu_chr_fe_write() { qemu_mutex_lock(&chr->chr_write_lock); ... qemu_mutex_unlock(&chr->chr_write_lock); } … } qemu_mutex_unlock(&chr->chr_write_lock); } Acquire mutex in this way cause deadlock. -----Original Message----- From: Peter Maydell [mailto:peter.mayd...@linaro.org] Sent: Friday, July 11, 2014 5:08 PM To: Li, LiangX Z Cc: QEMU Developers; Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] qemu-char: Fixed the bug lead to dead lock On 11 July 2014 05:58, Liliang <liangx.z...@intel.com> wrote: > From: Li Liang <liangx.z...@intel.com> > > This bug was introduced in the commit > 9005b2a7589540a3733b3abdcfbccfe7746cd1a1, > it will cause deadlock when create a vm with the parameter "-monitor > pty" and then try to read from /dev/pts/x. > > Signed-off-by: Li Liang <liangx.z...@intel.com> > --- > qemu-char.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/qemu-char.c b/qemu-char.c index 55e372c..55cdded 100644 > --- a/qemu-char.c > +++ b/qemu-char.c > @@ -1103,9 +1103,11 @@ static gboolean pty_chr_timer(gpointer opaque) > s->timer_tag = 0; > if (!s->connected) { > /* Next poll ... */ > + qemu_mutex_unlock(&chr->chr_write_lock); > pty_chr_update_read_handler_locked(chr); > + } else { > + qemu_mutex_unlock(&chr->chr_write_lock); > } > - qemu_mutex_unlock(&chr->chr_write_lock); > return FALSE; > } This is clearly not the correct fix -- it is now calling pty_chr_update_read_handler_locked() without holding the chr_write_lock mutex, which is not permitted. thanks -- PMM