[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