All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chai Wen <chaiw.fnst@cn.fujitsu.com>
To: kwolf@redhat.com, pbonzini@redhat.com,
	Fam Zheng <famz@redhat.com>,
	qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [Bug] block: virtio-blk-dataplane causes segfault
Date: Wed, 2 Jul 2014 11:52:22 +0800	[thread overview]
Message-ID: <53B381F6.10401@cn.fujitsu.com> (raw)
In-Reply-To: <53B37B57.3020507@cn.fujitsu.com>

On 07/02/2014 11:24 AM, Chai Wen wrote:

> Hi
> 
> I tested the latest release v2.1 qemu feature virtio-dataplane.
> And it seems that there is a little bug in it.
> Please see the following below for detail, thanks.
> 


Oh, Just saw Stefan's fix. Please ignore.

Stefan Hajnoczi (4):
  virtio-blk: avoid dataplane VirtIOBlockReq early free
  dataplane: do not free VirtQueueElement in vring_push()
  virtio-blk: avoid g_slice_new0() for VirtIOBlockReq and
    VirtQueueElement
  virtio-blk: embed VirtQueueElement in VirtIOBlockReq


thanks
chai wen

> git: git.qemu.org/qemu.git
> branch: master
> top commit:
> commit 92259b7f434b382fc865d1f65f7d5adeed295749
> Author: Peter Maydell <peter.maydell@linaro.org>
> Date:   Tue Jul 1 18:48:01 2014 +0100
> 
>     Update version for v2.1.0-rc0 release
> 
> 
> reproduce steps:
> ./qemu-system-x86_64 -enable-kvm -smp 2 -m 1024 -drive file=/var/vm_images/images/6G_smallsuse.img,if=none,format=raw,cache=none,id=image1 -device
> virtio-blk-pci,drive=image1,scsi=off,x-data-plane=on -net none
> Segmentation fault (core dumped)
> 
> 
> And I think there is something wrong in the completion callback chains for dataplane.
> static void complete_request_vring(VirtIOBlockReq *req, unsigned char status)
> {
>     stb_p(&req->in->status, status);
> 
>     vring_push(&req->dev->dataplane->vring, req->elem,
>                req->qiov.size + sizeof(*req->in));
>     notify_guest(req->dev->dataplane);
>     g_slice_free(VirtIOBlockReq, req);        <---
> }
> 
> static void virtio_blk_rw_complete(void *opaque, int ret)
> {
>     VirtIOBlockReq *req = opaque;
> 
>     trace_virtio_blk_rw_complete(req, ret);
> 
>     if (ret) {
>         int p = virtio_ldl_p(VIRTIO_DEVICE(req->dev), &req->out.type);
>         bool is_read = !(p & VIRTIO_BLK_T_OUT);
>         if (virtio_blk_handle_rw_error(req, -ret, is_read))
>             return;
>     }
> 
>     virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);    <---
>     bdrv_acct_done(req->dev->bs, &req->acct);         <---
>     virtio_blk_free_request(req);
> }
> 
> 
> 
> 
> (gdb) bt
> #0  0x000055555588236f in bdrv_acct_done (bs=0x48004800480048, cookie=0x5555563016e8) at block.c:5478
> #1  0x000055555564035b in virtio_blk_rw_complete (opaque=0x5555563016a0, ret=0) at /home/git_dev/qemu_115/qemu/hw/block/virtio-blk.c:99
> #2  0x0000555555883d22 in bdrv_co_em_bh (opaque=<value optimized out>) at block.c:4665
> #3  0x000055555587c9f7 in aio_bh_poll (ctx=0x5555562267f0) at async.c:81
> #4  0x000055555588dc17 in aio_poll (ctx=0x5555562267f0, blocking=true) at aio-posix.c:188
> #5  0x00005555556fa357 in iothread_run (opaque=0x555556227268) at iothread.c:41
> #6  0x00007ffff6bb9851 in start_thread () from /lib64/libpthread.so.0
> #7  0x00007ffff1ac890d in clone () from /lib64/libc.so.6
> (gdb) info thread
>   7 Thread 0x7fff9bfff700 (LWP 25553)  0x00007ffff6bbf811 in sem_timedwait () from /lib64/libpthread.so.0
>   6 Thread 0x7fffe61fd700 (LWP 25552)  0x00007ffff6bbd43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> * 5 Thread 0x7fffe69fe700 (LWP 25551)  0x000055555588236f in bdrv_acct_done (bs=0x48004800480048, cookie=0x5555563016e8) at block.c:5478
>   4 Thread 0x7fffe71ff700 (LWP 25550)  0x00007ffff6bbf811 in sem_timedwait () from /lib64/libpthread.so.0
>   3 Thread 0x7fffec9d8700 (LWP 25548)  0x00007ffff1ac0a47 in ioctl () from /lib64/libc.so.6
>   2 Thread 0x7fffed1d9700 (LWP 25547)  0x00007ffff1ac0a47 in ioctl () from /lib64/libc.so.6
>   1 Thread 0x7ffff7fc09a0 (LWP 25544)  0x00007ffff1abf487 in ppoll () from /lib64/libc.so.6
> 
> 



-- 
Regards

Chai Wen

      reply	other threads:[~2014-07-02  3:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-02  3:24 [Qemu-devel] [Bug] block: virtio-blk-dataplane causes segfault Chai Wen
2014-07-02  3:52 ` Chai Wen [this message]

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=53B381F6.10401@cn.fujitsu.com \
    --to=chaiw.fnst@cn.fujitsu.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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.