Am 02.04.2020 um 17:40 hat Dietmar Maurer geschrieben: > > Can you reproduce the problem with my script, but pointing it to your > > Debian image and running stress-ng instead of dd? > > yes > > > If so, how long does > > it take to reproduce for you? > > I sometimes need up to 130 iterations ... > > Worse, I thought several times the bug is gone, but then it triggered again > (sigh). > > But most times below 30 iteration (if you run "stress-ng -d 5"). > > Also note that it can happen at different places, but always inside a drained > section ...
I got a stracktrace of a hanging coroutine: (gdb) qemu coroutine 0x7fd8c00132c0 #0 0x00005630e16e9840 in qemu_coroutine_switch (from_=from_@entry=0x7fd8c00132c0, to_=to_@entry=0x7fd8cda865b8, action=action@entry=COROUTINE_YIELD) at util/coroutine-ucontext.c:218 #1 0x00005630e16e8521 in qemu_coroutine_yield () at util/qemu-coroutine.c:193 #2 0x00005630e16e8ba5 in qemu_co_queue_wait_impl (queue=queue@entry=0x5630e48ab580, lock=lock@entry=0x0) at util/qemu-coroutine-lock.c:56 #3 0x00005630e161f1ae in blk_wait_while_drained (blk=blk@entry=0x5630e48ab260) at /home/kwolf/source/qemu/include/qemu/lockable.h:46 #4 0x00005630e1620600 in blk_wait_while_drained (blk=0x5630e48ab260) at block/block-backend.c:1189 #5 0x00005630e1620600 in blk_co_pwritev_part (blk=0x5630e48ab260, offset=2922381312, bytes=856064, qiov=qiov@entry=0x7fd8c002cd70, qiov_offset=qiov_offset@entry=0, flags=0) at block/block-backend.c:1189 #6 0x00005630e16207ce in blk_co_pwritev (flags=<optimized out>, qiov=0x7fd8c002cd70, bytes=<optimized out>, offset=<optimized out>, blk=<optimized out>) at block/block-backend.c:1429 #7 0x00005630e16207ce in blk_aio_write_entry (opaque=0x7fd8c002cdc0) at block/block-backend.c:1429 #8 0x00005630e16e98bb in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:115 So I think this is the bug: Calling blk_wait_while_drained() from anywhere between blk_inc_in_flight() and blk_dec_in_flight() is wrong because it will deadlock the drain operation. blk_aio_read/write_entry() take care of this and drop their reference around blk_wait_while_drained(). But if we hit the race condition that drain hasn't yet started there, but it has when we get to blk_co_preadv() or blk_co_pwritev_part(), then we're in a buggy code path. Kevin