Hi James,
On Thu, 9 Nov 2017, 7:36am, James Smart wrote:
> 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.
>
Yes, Will work on removing spin lock.
> -- james
>
>
