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().
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
