All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "Richard W.M. Jones" <rjones@redhat.com>, Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>
Subject: Re: 9p broken?
Date: Tue, 31 Jul 2012 12:06:15 +0530	[thread overview]
Message-ID: <87d33csahs.fsf@skywalker.in.ibm.com> (raw)
In-Reply-To: <20120730220350.GB4000@amd.home.annexia.org>

"Richard W.M. Jones" <rjones@redhat.com> writes:

> On Mon, Jul 30, 2012 at 03:35:39PM +0300, Avi Kivity wrote:
>> Having an annoying bug on i386 kvm I decided to debug it buy running an
>> i386 guest on my x86_64 host, use 9p to access a guest image, and run it
>> using nested kvm.
>> 
>> However, 9p appears to be broken: first, the configure test fails (patch
>> sent).  Second, while mount works, ls on the mount point causes qemu to
>> crash with
>> 
>> (gdb) bt
>> #0  error_set (errp=0x7fffe95fb128, fmt=0x5555558d4568 "{ 'class':
>> 'VirtFSFeatureBlocksMigration', 'data': { 'path': %s, 'tag': %s } }") at
>> /home/tlv/akivity/qemu/error.c:32
>> #1  0x000055555567cb06 in v9fs_attach (opaque=0x7fffe95e3020) at
>> /home/tlv/akivity/qemu/hw/9pfs/virtio-9p.c:988
>> #2  0x000055555561d19f in coroutine_trampoline (i0=1449767888, i1=21845)
>> at /home/tlv/akivity/qemu/coroutine-ucontext.c:138
>> #3  0x00007ffff5a93ef0 in ?? ()	from /lib64/libc.so.6
>> #4  0x00007fffffffce00 in ?? ()
>> #5  0x0000000000000000 in ?? (
>> 
>> **errp already points to a VirtFSFeatureBlocksMigration error;
>> v9fs_attach() has been called a second time (the first time,
>> understandably, on mount; the second on ls).
>
> Yes, I can reproduce this too.
>
> LIBGUESTFS_QEMU=~/d/qemu/qemu.wrapper \
> guestfish -v -- \
>   sparse /tmp/unused 100M : \
>   config -device 'virtio-9p-pci,fsdev=root,mount_tag=root' : \
>   config -fsdev 'local,id=root,path=/tmp,security_model=passthrough' : \
>   run : \
>   mount-9p root / : \
>   ls /
>
> Stack trace:
>
> #0  0x00007fb1d4d19ba5 in __GI_raise (sig=sig@entry=6)
>     at ../nptl/sysdeps/unix/sysv/linux/raise.c:63
> #1  0x00007fb1d4d1b358 in __GI_abort () at abort.c:90
> #2  0x00007fb1d4d12972 in __assert_fail_base (fmt=
>     0x7fb1d4e5c8e8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
>     assertion=assertion@entry=0x7fb1d8e2e87e "*errp == ((void *)0)", 
>     file=file@entry=0x7fb1d8e56217 "error.c", line=line@entry=35, 
>     function=function@entry=
>     0x7fb1d8e2e8ca <__PRETTY_FUNCTION__.13983> "error_set") at assert.c:92
> #3  0x00007fb1d4d12a22 in __GI___assert_fail (assertion=assertion@entry=
>     0x7fb1d8e2e87e "*errp == ((void *)0)", file=file@entry=
>     0x7fb1d8e56217 "error.c", line=line@entry=35, function=function@entry=
>     0x7fb1d8e2e8ca <__PRETTY_FUNCTION__.13983> "error_set") at assert.c:101
> #4  0x00007fb1d8c1147f in error_set (errp=errp@entry=0x7fb1ce36a128, 
>     fmt=fmt@entry=
>     0x7fb1d8e39a78 "{ 'class': 'VirtFSFeatureBlocksMigration', 'data': { 'path': %s, 'tag': %s } }") at error.c:35
> #5  0x00007fb1d8c57f9b in v9fs_attach (opaque=0x7fb1ce352020)
>     at /home/rjones/d/qemu/hw/9pfs/virtio-9p.c:988
> #6  0x00007fb1d8c0fcfa in coroutine_trampoline (i0=<optimized out>, 
>     i1=<optimized out>) at coroutine-ucontext.c:138
> #7  0x00007fb1d4d2a2f0 in ?? () from /lib64/libc.so.6
> #8  0x00007fff51061aa0 in ?? ()
> #9  0xb5b5b5b5b5b5b5b5 in ?? ()
> #10 0x0000000000000000 in ?? ()
>
> I'll add a regression test for 9p to libguestfs so at least we will
> catch this in future during Fedora builds.
>

I am not able to reproduce this, I had to patch configure to fix some
compile errors, but then I am not hitting the crash. I am using the
latest qemu. We do the below in 9p

    error_set(&s->migration_blocker, QERR_VIRTFS_FEATURE_BLOCKS_MIGRATION,
              s->ctx.fs_root ? s->ctx.fs_root : "NULL", s->tag);

I am not sure how we can hit that assert() in error_set() ?. 
We allocate s via 

    s = (V9fsState *)virtio_common_init() which does

    vdev = g_malloc0(struct_size);

-aneesh

WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "Richard W.M. Jones" <rjones@redhat.com>, Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] 9p broken?
Date: Tue, 31 Jul 2012 12:06:15 +0530	[thread overview]
Message-ID: <87d33csahs.fsf@skywalker.in.ibm.com> (raw)
In-Reply-To: <20120730220350.GB4000@amd.home.annexia.org>

"Richard W.M. Jones" <rjones@redhat.com> writes:

> On Mon, Jul 30, 2012 at 03:35:39PM +0300, Avi Kivity wrote:
>> Having an annoying bug on i386 kvm I decided to debug it buy running an
>> i386 guest on my x86_64 host, use 9p to access a guest image, and run it
>> using nested kvm.
>> 
>> However, 9p appears to be broken: first, the configure test fails (patch
>> sent).  Second, while mount works, ls on the mount point causes qemu to
>> crash with
>> 
>> (gdb) bt
>> #0  error_set (errp=0x7fffe95fb128, fmt=0x5555558d4568 "{ 'class':
>> 'VirtFSFeatureBlocksMigration', 'data': { 'path': %s, 'tag': %s } }") at
>> /home/tlv/akivity/qemu/error.c:32
>> #1  0x000055555567cb06 in v9fs_attach (opaque=0x7fffe95e3020) at
>> /home/tlv/akivity/qemu/hw/9pfs/virtio-9p.c:988
>> #2  0x000055555561d19f in coroutine_trampoline (i0=1449767888, i1=21845)
>> at /home/tlv/akivity/qemu/coroutine-ucontext.c:138
>> #3  0x00007ffff5a93ef0 in ?? ()	from /lib64/libc.so.6
>> #4  0x00007fffffffce00 in ?? ()
>> #5  0x0000000000000000 in ?? (
>> 
>> **errp already points to a VirtFSFeatureBlocksMigration error;
>> v9fs_attach() has been called a second time (the first time,
>> understandably, on mount; the second on ls).
>
> Yes, I can reproduce this too.
>
> LIBGUESTFS_QEMU=~/d/qemu/qemu.wrapper \
> guestfish -v -- \
>   sparse /tmp/unused 100M : \
>   config -device 'virtio-9p-pci,fsdev=root,mount_tag=root' : \
>   config -fsdev 'local,id=root,path=/tmp,security_model=passthrough' : \
>   run : \
>   mount-9p root / : \
>   ls /
>
> Stack trace:
>
> #0  0x00007fb1d4d19ba5 in __GI_raise (sig=sig@entry=6)
>     at ../nptl/sysdeps/unix/sysv/linux/raise.c:63
> #1  0x00007fb1d4d1b358 in __GI_abort () at abort.c:90
> #2  0x00007fb1d4d12972 in __assert_fail_base (fmt=
>     0x7fb1d4e5c8e8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
>     assertion=assertion@entry=0x7fb1d8e2e87e "*errp == ((void *)0)", 
>     file=file@entry=0x7fb1d8e56217 "error.c", line=line@entry=35, 
>     function=function@entry=
>     0x7fb1d8e2e8ca <__PRETTY_FUNCTION__.13983> "error_set") at assert.c:92
> #3  0x00007fb1d4d12a22 in __GI___assert_fail (assertion=assertion@entry=
>     0x7fb1d8e2e87e "*errp == ((void *)0)", file=file@entry=
>     0x7fb1d8e56217 "error.c", line=line@entry=35, function=function@entry=
>     0x7fb1d8e2e8ca <__PRETTY_FUNCTION__.13983> "error_set") at assert.c:101
> #4  0x00007fb1d8c1147f in error_set (errp=errp@entry=0x7fb1ce36a128, 
>     fmt=fmt@entry=
>     0x7fb1d8e39a78 "{ 'class': 'VirtFSFeatureBlocksMigration', 'data': { 'path': %s, 'tag': %s } }") at error.c:35
> #5  0x00007fb1d8c57f9b in v9fs_attach (opaque=0x7fb1ce352020)
>     at /home/rjones/d/qemu/hw/9pfs/virtio-9p.c:988
> #6  0x00007fb1d8c0fcfa in coroutine_trampoline (i0=<optimized out>, 
>     i1=<optimized out>) at coroutine-ucontext.c:138
> #7  0x00007fb1d4d2a2f0 in ?? () from /lib64/libc.so.6
> #8  0x00007fff51061aa0 in ?? ()
> #9  0xb5b5b5b5b5b5b5b5 in ?? ()
> #10 0x0000000000000000 in ?? ()
>
> I'll add a regression test for 9p to libguestfs so at least we will
> catch this in future during Fedora builds.
>

I am not able to reproduce this, I had to patch configure to fix some
compile errors, but then I am not hitting the crash. I am using the
latest qemu. We do the below in 9p

    error_set(&s->migration_blocker, QERR_VIRTFS_FEATURE_BLOCKS_MIGRATION,
              s->ctx.fs_root ? s->ctx.fs_root : "NULL", s->tag);

I am not sure how we can hit that assert() in error_set() ?. 
We allocate s via 

    s = (V9fsState *)virtio_common_init() which does

    vdev = g_malloc0(struct_size);

-aneesh

  reply	other threads:[~2012-07-31  6:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-30 12:35 9p broken? Avi Kivity
2012-07-30 12:35 ` [Qemu-devel] " Avi Kivity
2012-07-30 22:03 ` Richard W.M. Jones
2012-07-30 22:03   ` Richard W.M. Jones
2012-07-31  6:36   ` Aneesh Kumar K.V [this message]
2012-07-31  6:36     ` Aneesh Kumar K.V
2012-07-31  6:51 ` Aneesh Kumar K.V
2012-07-31  6:51   ` [Qemu-devel] " Aneesh Kumar K.V
2012-07-31 12:16   ` Avi Kivity
2012-07-31 13:30     ` Aneesh Kumar K.V
2012-07-31 13:55       ` Avi Kivity
2012-07-31  7:17 ` Aneesh Kumar K.V
2012-07-31  7:17   ` [Qemu-devel] " Aneesh Kumar K.V

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=87d33csahs.fsf@skywalker.in.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@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 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.