Re: bdrv_drained_begin deadlock with io-threads

[Dietmar Maurer]

> That's a pretty big change, and I'm not sure how it's related to
> completed requests hanging in the thread pool instead of reentering the
> file-posix coroutine. But I also tested it enough that I'm confident
> it's really the first bad commit.
> 
> Maybe you want to try if your problem starts at the same commit?

Stefan already found that by bisecting last week:

See: https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg07629.html

But, IMHO the commit is not the reason for (my) bug - It just makes
it easier to trigger... I can see (my) bug sometimes with 4.1.1, although
I have no easy way to reproduce it reliable.

Also, Stefan sent some patches to the list to fix some of the problems.

https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg00022.html

Does that fix your problem?

I will run further tests with your script, thanks.

> Kevin
> 
> 
> #!/bin/bash
> 
> qmp() {
> cat <<EOF
> {'execute':'qmp_capabilities'}
> EOF
> 
> while true; do
> cat <<EOF
> { "execute": "drive-backup", "arguments": {
>   "job-id":"drive_image1","device": "drive_image1", "sync": "full", "target": 
> "/tmp/backup.raw" } }
> EOF
> sleep 1
> cat <<EOF
> { "execute": "block-job-cancel", "arguments": { "device": "drive_image1"} }
> EOF
> sleep 2
> done
> }
> 
> ./qemu-img create -f qcow2 /tmp/test.qcow2 4G
> for i in $(seq 0 1); do echo "write ${i}G 1G"; done | ./qemu-io 
> /tmp/test.qcow2
> 
> qmp | x86_64-softmmu/qemu-system-x86_64 \
>     -enable-kvm \
>     -machine pc \
>     -m 1G \
>     -object 'iothread,id=iothread-virtioscsi0' \
>     -device 'virtio-scsi-pci,id=virtioscsi0,iothread=iothread-virtioscsi0' \
>     -blockdev node-name=my_drive,driver=file,filename=/tmp/test.qcow2 \
>     -blockdev driver=qcow2,node-name=drive_image1,file=my_drive \
>     -device scsi-hd,drive=drive_image1,id=image1 \
>     -cdrom ~/images/iso/RHEL-8.0-20190116.1-x86_64-dvd1.iso \
>     -boot d \
>     -qmp stdio -monitor vc