Hi,
I am suspecting that commit 7e5cdb345f ("ide: Increment BB in-flight
counter for TRIM BH") introduced an issue in combination with draining.>From a debug session on a costumer's machine I gathered the following information: * The QEMU process hangs in aio_poll called during draining and doesn't progress. * The in_flight counter for the BlockDriverState is 0 and for the BlockBackend it is 1. * There is a blk_aio_pdiscard_entry request in the BlockBackend's queued_requests. * The drive is attached via ahci. I suspect that something like the following happened: 1. ide_issue_trim is called, and increments the in_flight counter. 2. ide_issue_trim_cb calls blk_aio_pdiscard. 3. somebody else starts draining. 4. ide_issue_trim_cb is called as the completion callback for blk_aio_pdiscard. 5. ide_issue_trim_cb issues yet another blk_aio_pdiscard request. 6. The request is added to the wait queue via blk_wait_while_drained, because draining has been started. 7. Nobody ever decrements the in_flight counter and draining can't finish. The issue occurs very rarely and is difficult to reproduce, but with the help of GDB, I'm able to do it rather reliably: 1. Use GDB to break on blk_aio_pdiscard. 2. Run mkfs.ext4 on a huge disk in the guest. 3. Issue a drive-backup QMP command after landing on the breakpoint. 4. Continue a few times in GDB. 5. After that I can observe the same situation as described above. I'd be happy about suggestions for how to fix it. Unfortunately, I don't see a clear-cut way at the moment. The only idea I have right now is to change the code to issue all discard requests at the same time, but I fear there might pitfalls with that? Best Regards, Fiona
