| Message ID | 1389709469-15111-2-git-send-email-farman@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c index 6dcdd1b..a8fde04 100644 --- a/hw/scsi/virtio-scsi.c +++ b/hw/scsi/virtio-scsi.c @@ -339,6 +339,7 @@ static void virtio_scsi_request_cancelled(SCSIRequest *r) req->resp.cmd->response = VIRTIO_SCSI_S_ABORTED; } virtio_scsi_complete_req(req); + bdrv_drain_all(); } static void virtio_scsi_fail_cmd_req(VirtIOSCSIReq *req)
When an unplug is triggered via QMP, the routine scsi_req_cancel is called to cancel any outstanding requests. However, the I/Os themselves were instantiated via an asynchronous call that will drive scsi_*_complete routines after the unplug call stack finishes. As all references to the request have been released by the cancel thread, the scsi_*_complete routines experience a range of failures when it attempts to manipulate the released storage. Before we exit back to scsi_req_cancel, we need to inform the asynchronous tasks that they were canceled. This will handle all the cleanup work performed by scsi_*_complete before we release all the references to the affected request(s). Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> --- hw/scsi/virtio-scsi.c | 1 + 1 file changed, 1 insertion(+)