* [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.