On 01/12/2017 08:45 AM, Fam Zheng wrote:
On Thu, 01/12 08:28, Eric Farman wrote:
- if (virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd)) !=
0)
+ ret = virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd));
+ if (ret == -EIO) {
+ cmd->resp.cmd.response = VIRTIO_SCSI_S_BAD_TARGET;
+ virtscsi_complete_cmd(vscsi, cmd);
Is this safe? Calling virtscsi_complete_cmd requires vq_lock but we don't seem
to have it here.
Hrm... Didn't notice that, and can't speak to its safety. I had a bit of
an I/O workload going to other disks, and things seemed okay, but it was by
no means an exhaustive test.
I can't use virtscsi_vq_done, which normally handles that acquire/release.
It calls virtqueue_get_buf prior to calling virtscsi_complete_cmd, which
returns NULL because the virtqueue is broken. Thus, no call to
virtscsi_complete_cmd.
Can I mock up a wrapping routine that only handles the lock and complete_cmd
call, and ignore the virtqueue components that virtscsi_vq_done does?
That sounds good to me, taking the vq_lock here around the call to
virtscsi_complete_cmd, just like virtscsi_kick_cmd().
Okay, working up a v2 today. Thanks!
Eric
Fam
Eric
Fam
+ } else if (ret != 0) {
return SCSI_MLQUEUE_HOST_BUSY;
+ }
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
