On 2014/7/3 18:41, Paolo Bonzini wrote:
> Il 03/07/2014 04:23, ChenLiang ha scritto:
>> Program received signal SIGABRT, Aborted.
>> 0x00007fd548355b55 in raise () from /lib64/libc.so.6
>> (gdb) bt
>> #0 0x00007fd548355b55 in raise () from /lib64/libc.so.6
>> #1 0x00007fd548357131 in abort () from /lib64/libc.so.6
>> #2 0x00007fd548393e0f in __libc_message () from /lib64/libc.so.6
>> #3 0x00007fd548399618 in malloc_printerr () from /lib64/libc.so.6
>> #4 0x00007fd54b15e80e in free_and_trace (mem=0x7fd54beb2230) at vl.c:2815
>> #5 0x00007fd54b3453cd in qemu_aio_release (p=0x7fd54beb2230) at block.c:4813
>> #6 0x00007fd54b15717d in dma_complete (dbs=0x7fd54beb2230, ret=0) at
>> dma-helpers.c:132
>> #7 0x00007fd54b157253 in dma_bdrv_cb (opaque=0x7fd54beb2230, ret=0) at
>> dma-helpers.c:148
>> #8 0x00007fd54b344db8 in bdrv_co_em_bh (opaque=0x7fd54bea4b30) at
>> block.c:4676
>> #9 0x00007fd54b335a72 in aio_bh_poll (ctx=0x7fd54bcec990) at async.c:81
>> #10 0x00007fd54b34b1b4 in aio_poll (ctx=0x7fd54bcec990, blocking=false) at
>> aio-posix.c:188
>> #11 0x00007fd54b335ee0 in aio_ctx_dispatch (source=0x7fd54bcec990,
>> callback=0x0, user_data=0x0) at async.c:211
>> #12 0x00007fd549e3669a in g_main_context_dispatch () from
>> /usr/lib64/libglib-2.0.so.0
>> #13 0x00007fd54b348c45 in glib_pollfds_poll () at main-loop.c:190
>> #14 0x00007fd54b348d3d in os_host_main_loop_wait (timeout=0) at
>> main-loop.c:235
>> #15 0x00007fd54b348e2f in main_loop_wait (nonblocking=0) at main-loop.c:484
>> #16 0x00007fd54b15b0f8 in main_loop () at vl.c:2007
>> #17 0x00007fd54b162a35 in main (argc=57, argv=0x7fff152720a8,
>> envp=0x7fff15272278) at vl.c:4526
>>
>> (gdb) bt
>> #0 qemu_aio_release (p=0x7f86420ebec0) at block.c:4811
>> #1 0x00007f86412b617d in dma_complete (dbs=0x7f86420ebec0, ret=0) at
>> dma-helpers.c:132
>> #2 0x00007f86412b65ab in dma_aio_cancel (acb=0x7f86420ebec0) at
>> dma-helpers.c:192
>> #3 0x00007f86414a3996 in bdrv_aio_cancel (acb=0x7f86420ebec0) at
>> block.c:4559
>> #4 0x00007f86413906af in ide_bus_reset (bus=0x7f8641fe3a20) at
>> hw/ide/core.c:2056
>> #5 0x00007f86413967d6 in piix3_reset (opaque=0x7f8641fe32a0) at
>> hw/ide/piix.c:114
>> #6 0x00007f86412b9a37 in qemu_devices_reset () at vl.c:1829
>> #7 0x00007f86412b9aef in qemu_system_reset (report=true) at vl.c:1842
>> #8 0x00007f86412b9fe2 in main_loop_should_exit () at vl.c:1971
>> #9 0x00007f86412ba100 in main_loop () at vl.c:2011
>> #10 0x00007f86412c1a35 in main (argc=57, argv=0x7fff2e827d38,
>> envp=0x7fff2e827f08) at vl.c:4526
>
> Ok, this is the same as your previous backtrace. The bug is still the same:
> dma_bdrv_cb must not be called dma_aio_cancel has finished the recursive call
> to bdrv_aio_cancel.
>
>> BTW, is it better to rename dbs->in_cancel to dbs->canceled ?
>
> If we were to apply my patch, yes. But with the current logic "in_cancel"
> says "are we inside the recursive call to bdrv_aio_cancel" so I think the
> answer is no. My patch is just a band-aid, I don't think it should be
> applied.
>
> Paolo
>
> .
>
Hi,
virtio_blk_reset uses bdrv_drain_all too.
static void virtio_blk_reset(VirtIODevice *vdev)
{
VirtIOBlock *s = VIRTIO_BLK(vdev);
#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
if (s->dataplane) {
virtio_blk_data_plane_stop(s->dataplane);
}
#endif
/*
* This should cancel pending requests, but can't do nicely until there
* are per-device request lists.
*/
bdrv_drain_all();
bdrv_set_enable_write_cache(s->bs, s->original_wce);
}
Best regards
Chenliang
