[PATCH 1/1] nvmet-fcloop: Check remoteport port_state before calling done callback

[Justin Tee]

> Is this what the hardware/driver would do as well? Originally, when
> adding this code it return always an error and James told me that this
> is not how the hardware/driver work. Though this was without checking
> the port_state.
>
> That said, I am fine doing this though, as it clearly fixes a problem.
> Just wondering how far we can deviate from the 'real' thing.

Great question, and I can help explain from lpfc driver perspective
that I think this patch does not deviate from real FC LLDD behavior:

For the lpfc driver, two sanity checks are made:

1.) In  __lpfc_nvme_xmt_ls_rsp, axchg->state is checked to have to be
in LPFC_NVME_STE_LS_RCV.  Otherwise, non-zero error is returned back
to nvme_fc transport when .xmt_ls_rsp is called.

2.) LPFC_NVME_STE_LS_RCV could only be set for a remoteport that is
online and has completed PRLI-NVME.  This check is in
lpfc_nvme_unsol_ls_handler with log message id 6216 in lpfc driver,
which is part of the queue work item after the interrupt handler for
unsolicited NVME frames.  An ndlp’s state (lpfc’s object for a
remoteport) is checked before setting axchg->state to
LPFC_NVME_STE_LS_RCV.