This is a note to let you know that I've just added the patch titled
scsi: lpfc: Resolve some cleanup issues following abort path refactoring
to the 5.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
scsi-lpfc-resolve-some-cleanup-issues-following-abort-path-refactoring.patch
and it can be found in the queue-5.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 24e1f056677eefe834d5dcf61905cce857ca4b19 Mon Sep 17 00:00:00 2001
From: James Smart <jsmart2021@xxxxxxxxx>
Date: Fri, 3 Jun 2022 10:43:22 -0700
Subject: scsi: lpfc: Resolve some cleanup issues following abort path refactoring
From: James Smart <jsmart2021@xxxxxxxxx>
commit 24e1f056677eefe834d5dcf61905cce857ca4b19 upstream.
Refactoring and consolidation of abort paths:
- lpfc_sli4_abort_fcp_cmpl() and lpfc_sli_abort_fcp_cmpl() are combined
into a single generic lpfc_sli_abort_fcp_cmpl() routine. Thus, remove
extraneous lpfc_sli4_abort_fcp_cmpl() prototype declaration.
- lpfc_nvme_abort_fcreq_cmpl() abort completion routine is called with a
mismatched argument type. This may result in misleading log message
content. Update to the correct argument type of lpfc_iocbq instead of
lpfc_wcqe_complete. The lpfc_wcqe_complete should be derived from the
lpfc_iocbq structure.
Link: https://lore.kernel.org/r/20220603174329.63777-3-jsmart2021@xxxxxxxxx
Fixes: 31a59f75702f ("scsi: lpfc: SLI path split: Refactor Abort paths")
Cc: <stable@xxxxxxxxxxxxxxx> # v5.18
Co-developed-by: Justin Tee <justin.tee@xxxxxxxxxxxx>
Signed-off-by: Justin Tee <justin.tee@xxxxxxxxxxxx>
Signed-off-by: James Smart <jsmart2021@xxxxxxxxx>
Signed-off-by: Martin K. Petersen <martin.petersen@xxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/scsi/lpfc/lpfc_crtn.h | 4 +---
drivers/scsi/lpfc/lpfc_nvme.c | 6 ++++--
2 files changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/scsi/lpfc/lpfc_crtn.h
+++ b/drivers/scsi/lpfc/lpfc_crtn.h
@@ -418,8 +418,6 @@ int lpfc_sli_issue_iocb_wait(struct lpfc
uint32_t);
void lpfc_sli_abort_fcp_cmpl(struct lpfc_hba *, struct lpfc_iocbq *,
struct lpfc_iocbq *);
-void lpfc_sli4_abort_fcp_cmpl(struct lpfc_hba *h, struct lpfc_iocbq *i,
- struct lpfc_wcqe_complete *w);
void lpfc_sli_free_hbq(struct lpfc_hba *, struct hbq_dmabuf *);
@@ -627,7 +625,7 @@ void lpfc_nvmet_invalidate_host(struct l
struct lpfc_nodelist *ndlp);
void lpfc_nvme_abort_fcreq_cmpl(struct lpfc_hba *phba,
struct lpfc_iocbq *cmdiocb,
- struct lpfc_wcqe_complete *abts_cmpl);
+ struct lpfc_iocbq *rspiocb);
void lpfc_create_multixri_pools(struct lpfc_hba *phba);
void lpfc_create_destroy_pools(struct lpfc_hba *phba);
void lpfc_move_xri_pvt_to_pbl(struct lpfc_hba *phba, u32 hwqid);
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -1741,7 +1741,7 @@ lpfc_nvme_fcp_io_submit(struct nvme_fc_l
* lpfc_nvme_abort_fcreq_cmpl - Complete an NVME FCP abort request.
* @phba: Pointer to HBA context object
* @cmdiocb: Pointer to command iocb object.
- * @abts_cmpl: Pointer to wcqe complete object.
+ * @rspiocb: Pointer to response iocb object.
*
* This is the callback function for any NVME FCP IO that was aborted.
*
@@ -1750,8 +1750,10 @@ lpfc_nvme_fcp_io_submit(struct nvme_fc_l
**/
void
lpfc_nvme_abort_fcreq_cmpl(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb,
- struct lpfc_wcqe_complete *abts_cmpl)
+ struct lpfc_iocbq *rspiocb)
{
+ struct lpfc_wcqe_complete *abts_cmpl = &rspiocb->wcqe_cmpl;
+
lpfc_printf_log(phba, KERN_INFO, LOG_NVME,
"6145 ABORT_XRI_CN completing on rpi x%x "
"original iotag x%x, abort cmd iotag x%x "
Patches currently in stable-queue which might be from jsmart2021@xxxxxxxxx are
queue-5.18/scsi-lpfc-correct-bde-type-for-xmit_seq64_wqe-in-lpf.patch
queue-5.18/scsi-lpfc-address-null-pointer-dereference-after-starget_to_rport.patch
queue-5.18/scsi-lpfc-resolve-some-cleanup-issues-following-abort-path-refactoring.patch
queue-5.18/scsi-lpfc-resolve-some-cleanup-issues-following-sli-path-refactoring.patch
