Stressing the VDI code with qemu-img:

  qemu-img convert -p -W -m 16 -O vdi input.qcow2 output.vdi

leads to a hang relatively quickly on a machine with sufficient
CPUs. A similar test targetting either raw or qcow2 formats, or
avoiding out-of-order writes, completes fine.

At the point of the hang all of the coroutines are sitting in
qemu_co_queue_wait_impl(), called from either qemu_co_rwlock_rdlock()
or qemu_co_rwlock_upgrade(), all referencing the same CoRwlock
(BDRVVdiState.bmap_lock).

The comment in the last patch explains what I believe is happening -
downgrading an rwlock from write to read can later result in a failure
to schedule an appropriate coroutine when the read lock is released.

A less invasive change might be to simply have the read side of the
unlock code mark *all* queued coroutines as runnable. This seems
somewhat wasteful, as any read hopefuls that run before a write
hopeful will immediately put themselves back on the queue.

No code other than block/vdi.c appears to use
qemu_co_rwlock_downgrade().

The block/vdi.c changes are small things noticed by inspection when
looking for the cause of the hang.

v2:
- Add some r-by (Philippe, Paolo).
- Add a test for the rwlock downgrade behaviour (Paolo).
- Improve unlock to avoid thundering herd (Paolo).

David Edmondson (6):
  block/vdi: When writing new bmap entry fails, don't leak the buffer
  block/vdi: Don't assume that blocks are larger than VdiHeader
  coroutine/mutex: Store the coroutine in the CoWaitRecord only once
  test-coroutine: Add rwlock downgrade test
  coroutine/rwlock: Wake writers in preference to readers
  coroutine/rwlock: Avoid thundering herd when unlocking

 block/vdi.c                |  11 ++--
 include/qemu/coroutine.h   |   8 ++-
 tests/test-coroutine.c     | 112 +++++++++++++++++++++++++++++++++++++
 util/qemu-coroutine-lock.c |  27 ++++-----
 4 files changed, 138 insertions(+), 20 deletions(-)

-- 
2.30.1