[PATCH v2 1/4] qla2xxx_nvmet: Add files for FC-NVMe Target support

James Smart james.smart at broadcom.com
Thu Nov 9 07:36:22 PST 2017


On 11/8/2017 7:17 PM, Himanshu Madhani wrote:
> +static struct nvmet_fc_target_template qla_nvmet_fc_transport = {
> +	.targetport_delete	= qla_nvmet_targetport_delete,
> +	.xmt_ls_rsp		= qla_nvmet_ls_rsp,
> +	.fcp_op			= qla_nvmet_fcp_op,
> +	.fcp_abort		= qla_nvmet_fcp_abort,
> +	.fcp_req_release	= qla_nvmet_fcp_req_release,
> +	.max_hw_queues		= 8,
> +	.max_sgl_segments	= 128,
> +	.max_dif_sgl_segments	= 64,
> +	.dma_boundary		= 0xFFFFFFFF,
> +	.target_features	= NVMET_FCTGTFEAT_READDATA_RSP |
> +					NVMET_FCTGTFEAT_CMD_IN_ISR |
> +					NVMET_FCTGTFEAT_OPDONE_IN_ISR,
> +	.target_priv_sz	= sizeof(struct nvme_private),
> +};
>

 From the patch set prior:
 > Agree we do nvme_fc* callbacks in deferred context, but without the 
xxx_IN_ISR flag during NVMe Target template registration, we were 
running into crash due to recursive spin_lock held as part of CTIO 
response in our driver.

Can you look into removing this recursive spin lock ?    I don't think 
it's a good idea to be holding a spin lock when upcalling the transport.

-- james




More information about the Linux-nvme mailing list