Re: [PATCH] virtio_scsi: Reject commands when virtqueue is broken

[Fam Zheng <famz@redhat.com>]

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;
> > >  }
> > 
>