[Qemu-devel] [Bug] block: virtio-blk-dataplane causes segfault

[Chai Wen]

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.

git: git.qemu.org/qemu.git
branch: master
top commit:
commit 92259b7f434b382fc865d1f65f7d5adeed295749
Author: Peter Maydell <address@hidden>
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