* [Qemu-devel] glib mainloop breaks virtfs
@ 2011-09-06 11:22 Gerd Hoffmann
2011-09-06 14:31 ` Anthony Liguori
2011-09-07 10:44 ` Aneesh Kumar K.V
0 siblings, 2 replies; 6+ messages in thread
From: Gerd Hoffmann @ 2011-09-06 11:22 UTC (permalink / raw)
To: qemu-devel, Anthony Liguori
Hi,
virtfs stopped working for me in master, the guest (fedora 15) just
hangs at boot when mounting the virtfs filesystems. Bisecting points to
this commit:
rincewind kraxel ~/projects/qemu ((69e5bb6...)|BISECTING)# git bisect good
4d88a2ac8643265108ef1fb47ceee5d7b28e19f2 is the first bad commit
commit 4d88a2ac8643265108ef1fb47ceee5d7b28e19f2
Author: Anthony Liguori <aliguori@us.ibm.com>
Date: Mon Aug 22 08:12:53 2011 -0500
main: switch qemu_set_fd_handler to g_io_add_watch
cheers,
Gerd
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Qemu-devel] glib mainloop breaks virtfs 2011-09-06 11:22 [Qemu-devel] glib mainloop breaks virtfs Gerd Hoffmann @ 2011-09-06 14:31 ` Anthony Liguori 2011-09-06 17:25 ` Aneesh Kumar K.V 2011-09-07 10:44 ` Aneesh Kumar K.V 1 sibling, 1 reply; 6+ messages in thread From: Anthony Liguori @ 2011-09-06 14:31 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: qemu-devel, Aneesh Kumar K.V On 09/06/2011 06:22 AM, Gerd Hoffmann wrote: > Hi, > > virtfs stopped working for me in master, the guest (fedora 15) just > hangs at boot when mounting the virtfs filesystems. Bisecting points to > this commit: > > rincewind kraxel ~/projects/qemu ((69e5bb6...)|BISECTING)# git bisect good > 4d88a2ac8643265108ef1fb47ceee5d7b28e19f2 is the first bad commit > commit 4d88a2ac8643265108ef1fb47ceee5d7b28e19f2 > Author: Anthony Liguori <aliguori@us.ibm.com> > Date: Mon Aug 22 08:12:53 2011 -0500 > > main: switch qemu_set_fd_handler to g_io_add_watch The v9fs code uses qemu_set_fd_handler to trigger coroutines. I suspect this is not going to be a fun one to debug. This changeset changes the ordering of when callbacks are fired so it may be triggering a latent bug in the coroutine usage in virtio-9p. Aneesh, can you take a look at it? Regards, Anthony Liguori > > cheers, > Gerd > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] glib mainloop breaks virtfs 2011-09-06 14:31 ` Anthony Liguori @ 2011-09-06 17:25 ` Aneesh Kumar K.V 2011-09-06 17:41 ` Aneesh Kumar K.V 0 siblings, 1 reply; 6+ messages in thread From: Aneesh Kumar K.V @ 2011-09-06 17:25 UTC (permalink / raw) To: Anthony Liguori, Gerd Hoffmann; +Cc: qemu-devel On Tue, 06 Sep 2011 09:31:32 -0500, Anthony Liguori <anthony@codemonkey.ws> wrote: > On 09/06/2011 06:22 AM, Gerd Hoffmann wrote: > > Hi, > > > > virtfs stopped working for me in master, the guest (fedora 15) just > > hangs at boot when mounting the virtfs filesystems. Bisecting points to > > this commit: > > > > rincewind kraxel ~/projects/qemu ((69e5bb6...)|BISECTING)# git bisect good > > 4d88a2ac8643265108ef1fb47ceee5d7b28e19f2 is the first bad commit > > commit 4d88a2ac8643265108ef1fb47ceee5d7b28e19f2 > > Author: Anthony Liguori <aliguori@us.ibm.com> > > Date: Mon Aug 22 08:12:53 2011 -0500 > > > > main: switch qemu_set_fd_handler to g_io_add_watch > > The v9fs code uses qemu_set_fd_handler to trigger coroutines. I suspect > this is not going to be a fun one to debug. > > This changeset changes the ordering of when callbacks are fired so it > may be triggering a latent bug in the coroutine usage in virtio-9p. > Aneesh, can you take a look at it? > With master 344eecf6995f4a0ad1d887cec922f6806f91a3f8 I am getting SIGABRT *** glibc detected *** /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64: corrupted double-linked list: 0x000000000154ed60 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x76bb6)[0x7ffff5a9abb6] /lib/x86_64-linux-gnu/libc.so.6(+0x7a931)[0x7ffff5a9e931] /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x6e)[0x7ffff5aa031e] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x4f3b36] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_malloc+0x23)[0x7ffff7524a63] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_io_channel_unix_new+0x15)[0x7ffff7562635] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x46a019] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x4ed2e3] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x4ed3d3] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x4ed7a3] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x4edc7e] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x5e10ef] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x46ad04] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x46a73d] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x46b0ff] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x5d6740] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x5d6cbc] /home/kvaneesh/bin-local/qemu-9p/bin/qemu-system-x86_64[0x5a9996] /lib/x86_64-linux-gnu/libpthread.so.0(+0x6d8c)[0x7ffff5dbed8c] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7ffff5b0a04d] gdb stack Program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff1ec8700 (LWP 4384)] 0x00007ffff5a57d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) where #0 0x00007ffff5a57d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff5a5bab6 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff5a90d7b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007ffff5a9abb6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00007ffff5a9e931 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x00007ffff5aa031e in malloc () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x00000000004f3b36 in malloc_and_trace (n_bytes=120) at /home/opensource/sources/qemu/qemu-upstream/vl.c:2146 #7 0x00007ffff7524a63 in g_malloc () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x00007ffff7562635 in g_io_channel_unix_new () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x000000000046a019 in qemu_set_fd_handler (fd=18, fd_read=0x4ed205 <virtio_pci_host_notifier_read>, fd_write=0, opaque=0x14d7190) at /home/opensource/sources/qemu/qemu-upstream/iohandler.c:139 #10 0x00000000004ed2e3 in virtio_pci_set_host_notifier_fd_handler (proxy=0x14d6440, n=0, assign=true) at /home/opensource/sources/qemu/qemu-upstream/hw/virtio-pci.c:206 #11 0x00000000004ed3d3 in virtio_pci_start_ioeventfd (proxy=0x14d6440) at /home/opensource/sources/qemu/qemu-upstream/hw/virtio-pci.c:234 #12 0x00000000004ed7a3 in virtio_ioport_write (opaque=0x14d6440, addr=18, val=7) at /home/opensource/sources/qemu/qemu-upstream/hw/virtio-pci.c:329 #13 0x00000000004edc7e in virtio_pci_config_writeb (opaque=0x14d6440, addr=18, val=7) at /home/opensource/sources/qemu/qemu-upstream/hw/virtio-pci.c:446 #14 0x00000000005e10ef in memory_region_iorange_write (iorange=0x14d68e8, offset=18, width=1, data=7) at /home/opensource/sources/qemu/qemu-upstream/memory.c:421 #15 0x000000000046ad04 in ioport_writeb_thunk (opaque=0x14d68e8, addr=49234, data=7) at /home/opensource/sources/qemu/qemu-upstream/ioport.c:210 #16 0x000000000046a73d in ioport_write (index=0, address=49234, data=7) at /home/opensource/sources/qemu/qemu-upstream/ioport.c:81 #17 0x000000000046b0ff in cpu_outb (addr=49234, val=7 '\a') at /home/opensource/sources/qemu/qemu-upstream/ioport.c:273 #18 0x00000000005d6740 in kvm_handle_io (port=49234, data=0x7ffff7ff3000, direction=1, size=1, count=1) at /home/opensource/sources/qemu/qemu-upstream/kvm-all.c:834 #19 0x00000000005d6cbc in kvm_cpu_exec (env=0x123a430) at /home/opensource/sources/qemu/qemu-upstream/kvm-all.c:976 #20 0x00000000005a9996 in qemu_kvm_cpu_thread_fn (arg=0x123a430) at /home/opensource/sources/qemu/qemu-upstream/cpus.c:661 #21 0x00007ffff5dbed8c in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #22 0x00007ffff5b0a04d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #23 0x0000000000000000 in ?? () (gdb) Reverting 4d88a2ac8643265108ef1fb47ceee5d7b28e19f2 fixes the issue. This is on ubuntu 11.04. -aneesh ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] glib mainloop breaks virtfs 2011-09-06 17:25 ` Aneesh Kumar K.V @ 2011-09-06 17:41 ` Aneesh Kumar K.V 0 siblings, 0 replies; 6+ messages in thread From: Aneesh Kumar K.V @ 2011-09-06 17:41 UTC (permalink / raw) To: Anthony Liguori, Gerd Hoffmann; +Cc: qemu-devel On Tue, 06 Sep 2011 22:55:17 +0530, "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote: > On Tue, 06 Sep 2011 09:31:32 -0500, Anthony Liguori <anthony@codemonkey.ws> wrote: > > On 09/06/2011 06:22 AM, Gerd Hoffmann wrote: > > > Hi, > > > > > > virtfs stopped working for me in master, the guest (fedora 15) just > > > hangs at boot when mounting the virtfs filesystems. Bisecting points to > > > this commit: > > > > > > rincewind kraxel ~/projects/qemu ((69e5bb6...)|BISECTING)# git bisect good > > > 4d88a2ac8643265108ef1fb47ceee5d7b28e19f2 is the first bad commit > > > commit 4d88a2ac8643265108ef1fb47ceee5d7b28e19f2 > > > Author: Anthony Liguori <aliguori@us.ibm.com> > > > Date: Mon Aug 22 08:12:53 2011 -0500 > > > > > > main: switch qemu_set_fd_handler to g_io_add_watch > > > > The v9fs code uses qemu_set_fd_handler to trigger coroutines. I suspect > > this is not going to be a fun one to debug. > > > > This changeset changes the ordering of when callbacks are fired so it > > may be triggering a latent bug in the coroutine usage in virtio-9p. > > Aneesh, can you take a look at it? > > > > With master 344eecf6995f4a0ad1d887cec922f6806f91a3f8 I am getting SIGABRT > With the below change i can reproduce the hang. I will take a look at virtfs co-routine use of qemu_set_fd_handler. Any reason why we check for opaque in qemu_set_fd_handler ? diff --git a/iohandler.c b/iohandler.c index 5ef66fb..aaeb20d 100644 --- a/iohandler.c +++ b/iohandler.c @@ -121,7 +121,7 @@ int qemu_set_fd_handler(int fd, g_source_remove(tramp->tag); } - if (opaque) { + GIOCondition cond = 0; tramp->fd_read = fd_read; @@ -138,7 +138,6 @@ int qemu_set_fd_handler(int fd, tramp->chan = g_io_channel_unix_new(fd); tramp->tag = g_io_add_watch(tramp->chan, cond, fd_trampoline, tramp); - } return 0; } ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] glib mainloop breaks virtfs 2011-09-06 11:22 [Qemu-devel] glib mainloop breaks virtfs Gerd Hoffmann 2011-09-06 14:31 ` Anthony Liguori @ 2011-09-07 10:44 ` Aneesh Kumar K.V 2011-09-07 10:58 ` Gerd Hoffmann 1 sibling, 1 reply; 6+ messages in thread From: Aneesh Kumar K.V @ 2011-09-07 10:44 UTC (permalink / raw) To: Gerd Hoffmann, qemu-devel, Anthony Liguori On Tue, 06 Sep 2011 13:22:36 +0200, Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi, > > virtfs stopped working for me in master, the guest (fedora 15) just > hangs at boot when mounting the virtfs filesystems. Bisecting points to > this commit: > > rincewind kraxel ~/projects/qemu ((69e5bb6...)|BISECTING)# git bisect good > 4d88a2ac8643265108ef1fb47ceee5d7b28e19f2 is the first bad commit > commit 4d88a2ac8643265108ef1fb47ceee5d7b28e19f2 > Author: Anthony Liguori <aliguori@us.ibm.com> > Date: Mon Aug 22 08:12:53 2011 -0500 > > main: switch qemu_set_fd_handler to g_io_add_watch > > cheers, > Gerd > The below patch fix the problem for me. commit 52ed37a201d34a3070b4e2d0f21b5e6cca50352e Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Date: Wed Sep 7 16:11:03 2011 +0530 iohandler: update qemu_fd_set_handler to work with null call back arg Many users of qemu_fd_set_handler including VirtFS use NULL call back arg. Update fd_trampoline and qemu_fd_set_handler to work with NULL call back arg Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> diff --git a/iohandler.c b/iohandler.c index 5ef66fb..b803208 100644 --- a/iohandler.c +++ b/iohandler.c @@ -93,10 +93,6 @@ static gboolean fd_trampoline(GIOChannel *chan, GIOCondition cond, gpointer opaq { IOTrampoline *tramp = opaque; - if (tramp->opaque == NULL) { - return FALSE; - } - if ((cond & G_IO_IN) && tramp->fd_read) { tramp->fd_read(tramp->opaque); } @@ -113,6 +109,7 @@ int qemu_set_fd_handler(int fd, IOHandler *fd_write, void *opaque) { + GIOCondition cond = 0; static IOTrampoline fd_trampolines[FD_SETSIZE]; IOTrampoline *tramp = &fd_trampolines[fd]; @@ -121,25 +118,21 @@ int qemu_set_fd_handler(int fd, g_source_remove(tramp->tag); } - if (opaque) { - GIOCondition cond = 0; - - tramp->fd_read = fd_read; - tramp->fd_write = fd_write; - tramp->opaque = opaque; - - if (fd_read) { - cond |= G_IO_IN | G_IO_ERR; - } + tramp->fd_read = fd_read; + tramp->fd_write = fd_write; + tramp->opaque = opaque; - if (fd_write) { - cond |= G_IO_OUT | G_IO_ERR; - } + if (fd_read) { + cond |= G_IO_IN | G_IO_ERR; + } - tramp->chan = g_io_channel_unix_new(fd); - tramp->tag = g_io_add_watch(tramp->chan, cond, fd_trampoline, tramp); + if (fd_write) { + cond |= G_IO_OUT | G_IO_ERR; } + tramp->chan = g_io_channel_unix_new(fd); + tramp->tag = g_io_add_watch(tramp->chan, cond, fd_trampoline, tramp); + return 0; } ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] glib mainloop breaks virtfs 2011-09-07 10:44 ` Aneesh Kumar K.V @ 2011-09-07 10:58 ` Gerd Hoffmann 0 siblings, 0 replies; 6+ messages in thread From: Gerd Hoffmann @ 2011-09-07 10:58 UTC (permalink / raw) To: Aneesh Kumar K.V; +Cc: Anthony Liguori, qemu-devel > commit 52ed37a201d34a3070b4e2d0f21b5e6cca50352e > Author: Aneesh Kumar K.V<aneesh.kumar@linux.vnet.ibm.com> > Date: Wed Sep 7 16:11:03 2011 +0530 > > iohandler: update qemu_fd_set_handler to work with null call back arg > > Many users of qemu_fd_set_handler including VirtFS use NULL call back arg. > Update fd_trampoline and qemu_fd_set_handler to work with NULL call back arg Patch applied, everything works again. thanks, Gerd ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-09-07 10:58 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-06 11:22 [Qemu-devel] glib mainloop breaks virtfs Gerd Hoffmann 2011-09-06 14:31 ` Anthony Liguori 2011-09-06 17:25 ` Aneesh Kumar K.V 2011-09-06 17:41 ` Aneesh Kumar K.V 2011-09-07 10:44 ` Aneesh Kumar K.V 2011-09-07 10:58 ` Gerd Hoffmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.