All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Mike Christie <michael.christie@oracle.com>
Cc: stefanha@redhat.com, linux-scsi@vger.kernel.org,
	target-devel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 1/1] vhost scsi: fix lun reset completion handling
Date: Wed, 18 Nov 2020 03:56:22 -0500	[thread overview]
Message-ID: <20201118035452-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1605680660-3671-1-git-send-email-michael.christie@oracle.com>

On Wed, Nov 18, 2020 at 12:24:20AM -0600, Mike Christie wrote:
> vhost scsi owns the scsi se_cmd but lio frees the se_cmd->se_tmr
> before calling release_cmd, so while with normal cmd completion we
> can access the se_cmd from the vhost work, we can't do the same with
> se_cmd->se_tmr. This has us copy the tmf response in
> vhost_scsi_queue_tm_rsp to our internal vhost-scsi tmf struct for
> when it gets sent to the guest from our worker thread.
> 
> Signed-off-by: Mike Christie <michael.christie@oracle.com>

Is this a fix for
    vhost scsi: Add support for LUN resets.

If so pls add a Fixes: tag.

> ---
>  drivers/vhost/scsi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index f22fce5..6ff8a5096 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -220,6 +220,7 @@ struct vhost_scsi_tmf {
>  	struct list_head queue_entry;
>  
>  	struct se_cmd se_cmd;
> +	u8 scsi_resp;
>  	struct vhost_scsi_inflight *inflight;
>  	struct iovec resp_iov;
>  	int in_iovs;
> @@ -426,6 +427,7 @@ static void vhost_scsi_queue_tm_rsp(struct se_cmd *se_cmd)
>  	struct vhost_scsi_tmf *tmf = container_of(se_cmd, struct vhost_scsi_tmf,
>  						  se_cmd);
>  
> +	tmf->scsi_resp = se_cmd->se_tmr_req->response;
>  	transport_generic_free_cmd(&tmf->se_cmd, 0);
>  }
>  
> @@ -1183,7 +1185,7 @@ static void vhost_scsi_tmf_resp_work(struct vhost_work *work)
>  						  vwork);
>  	int resp_code;
>  
> -	if (tmf->se_cmd.se_tmr_req->response == TMR_FUNCTION_COMPLETE)
> +	if (tmf->scsi_resp == TMR_FUNCTION_COMPLETE)
>  		resp_code = VIRTIO_SCSI_S_FUNCTION_SUCCEEDED;
>  	else
>  		resp_code = VIRTIO_SCSI_S_FUNCTION_REJECTED;
> -- 
> 1.8.3.1


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Mike Christie <michael.christie@oracle.com>
Cc: target-devel@vger.kernel.org, linux-scsi@vger.kernel.org,
	stefanha@redhat.com, virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 1/1] vhost scsi: fix lun reset completion handling
Date: Wed, 18 Nov 2020 03:56:22 -0500	[thread overview]
Message-ID: <20201118035452-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1605680660-3671-1-git-send-email-michael.christie@oracle.com>

On Wed, Nov 18, 2020 at 12:24:20AM -0600, Mike Christie wrote:
> vhost scsi owns the scsi se_cmd but lio frees the se_cmd->se_tmr
> before calling release_cmd, so while with normal cmd completion we
> can access the se_cmd from the vhost work, we can't do the same with
> se_cmd->se_tmr. This has us copy the tmf response in
> vhost_scsi_queue_tm_rsp to our internal vhost-scsi tmf struct for
> when it gets sent to the guest from our worker thread.
> 
> Signed-off-by: Mike Christie <michael.christie@oracle.com>

Is this a fix for
    vhost scsi: Add support for LUN resets.

If so pls add a Fixes: tag.

> ---
>  drivers/vhost/scsi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index f22fce5..6ff8a5096 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -220,6 +220,7 @@ struct vhost_scsi_tmf {
>  	struct list_head queue_entry;
>  
>  	struct se_cmd se_cmd;
> +	u8 scsi_resp;
>  	struct vhost_scsi_inflight *inflight;
>  	struct iovec resp_iov;
>  	int in_iovs;
> @@ -426,6 +427,7 @@ static void vhost_scsi_queue_tm_rsp(struct se_cmd *se_cmd)
>  	struct vhost_scsi_tmf *tmf = container_of(se_cmd, struct vhost_scsi_tmf,
>  						  se_cmd);
>  
> +	tmf->scsi_resp = se_cmd->se_tmr_req->response;
>  	transport_generic_free_cmd(&tmf->se_cmd, 0);
>  }
>  
> @@ -1183,7 +1185,7 @@ static void vhost_scsi_tmf_resp_work(struct vhost_work *work)
>  						  vwork);
>  	int resp_code;
>  
> -	if (tmf->se_cmd.se_tmr_req->response == TMR_FUNCTION_COMPLETE)
> +	if (tmf->scsi_resp == TMR_FUNCTION_COMPLETE)
>  		resp_code = VIRTIO_SCSI_S_FUNCTION_SUCCEEDED;
>  	else
>  		resp_code = VIRTIO_SCSI_S_FUNCTION_REJECTED;
> -- 
> 1.8.3.1

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  parent reply	other threads:[~2020-11-18  8:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18  6:24 [PATCH 1/1] vhost scsi: fix lun reset completion handling Mike Christie
2020-11-18  8:51 ` Stefan Hajnoczi
2020-11-18  8:51   ` Stefan Hajnoczi
2020-11-18  8:56 ` Michael S. Tsirkin [this message]
2020-11-18  8:56   ` Michael S. Tsirkin
2020-11-18 16:18   ` Mike Christie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201118035452-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michael.christie@oracle.com \
    --cc=stefanha@redhat.com \
    --cc=target-devel@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.