From: Greg Kroah-Hartman Date: Mon, 21 Feb 2022 07:03:43 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v4.9.303~22 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bf58a7ac49f5dca488f776231a2e0c5ff5041306;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: edac-fix-calculation-of-returned-address-and-next-offset-in-edac_align_ptr.patch scsi-lpfc-fix-pt2pt-nvme-prli-reject-logo-loop.patch --- diff --git a/queue-5.4/edac-fix-calculation-of-returned-address-and-next-offset-in-edac_align_ptr.patch b/queue-5.4/edac-fix-calculation-of-returned-address-and-next-offset-in-edac_align_ptr.patch new file mode 100644 index 00000000000..cfeeb88ddec --- /dev/null +++ b/queue-5.4/edac-fix-calculation-of-returned-address-and-next-offset-in-edac_align_ptr.patch @@ -0,0 +1,45 @@ +From f8efca92ae509c25e0a4bd5d0a86decea4f0c41e Mon Sep 17 00:00:00 2001 +From: Eliav Farber +Date: Thu, 13 Jan 2022 10:06:19 +0000 +Subject: EDAC: Fix calculation of returned address and next offset in edac_align_ptr() + +From: Eliav Farber + +commit f8efca92ae509c25e0a4bd5d0a86decea4f0c41e upstream. + +Do alignment logic properly and use the "ptr" local variable for +calculating the remainder of the alignment. + +This became an issue because struct edac_mc_layer has a size that is not +zero modulo eight, and the next offset that was prepared for the private +data was unaligned, causing an alignment exception. + +The patch in Fixes: which broke this actually wanted to "what we +actually care about is the alignment of the actual pointer that's about +to be returned." But it didn't check that alignment. + +Use the correct variable "ptr" for that. + + [ bp: Massage commit message. ] + +Fixes: 8447c4d15e35 ("edac: Do alignment logic properly in edac_align_ptr()") +Signed-off-by: Eliav Farber +Signed-off-by: Borislav Petkov +Cc: +Link: https://lore.kernel.org/r/20220113100622.12783-2-farbere@amazon.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/edac/edac_mc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/edac/edac_mc.c ++++ b/drivers/edac/edac_mc.c +@@ -263,7 +263,7 @@ void *edac_align_ptr(void **p, unsigned + else + return (char *)ptr; + +- r = (unsigned long)p % align; ++ r = (unsigned long)ptr % align; + + if (r == 0) + return (char *)ptr; diff --git a/queue-5.4/scsi-lpfc-fix-pt2pt-nvme-prli-reject-logo-loop.patch b/queue-5.4/scsi-lpfc-fix-pt2pt-nvme-prli-reject-logo-loop.patch new file mode 100644 index 00000000000..c55436ea1ad --- /dev/null +++ b/queue-5.4/scsi-lpfc-fix-pt2pt-nvme-prli-reject-logo-loop.patch @@ -0,0 +1,111 @@ +From 7f4c5a26f735dea4bbc0eb8eb9da99cda95a8563 Mon Sep 17 00:00:00 2001 +From: James Smart +Date: Sat, 12 Feb 2022 08:31:20 -0800 +Subject: scsi: lpfc: Fix pt2pt NVMe PRLI reject LOGO loop + +From: James Smart + +commit 7f4c5a26f735dea4bbc0eb8eb9da99cda95a8563 upstream. + +When connected point to point, the driver does not know the FC4's supported +by the other end. In Fabrics, it can query the nameserver. Thus the driver +must send PRLIs for the FC4s it supports and enable support based on the +acc(ept) or rej(ect) of the respective FC4 PRLI. Currently the driver +supports SCSI and NVMe PRLIs. + +Unfortunately, although the behavior is per standard, many devices have +come to expect only SCSI PRLIs. In this particular example, the NVMe PRLI +is properly RJT'd but the target decided that it must LOGO after seeing the +unexpected NVMe PRLI. The LOGO causes the sequence to restart and login is +now in an infinite failure loop. + +Fix the problem by having the driver, on a pt2pt link, remember NVMe PRLI +accept or reject status across logout as long as the link stays "up". When +retrying login, if the prior NVMe PRLI was rejected, it will not be sent on +the next login. + +Link: https://lore.kernel.org/r/20220212163120.15385-1-jsmart2021@gmail.com +Cc: # v5.4+ +Reviewed-by: Ewan D. Milne +Signed-off-by: James Smart +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/lpfc/lpfc.h | 1 + + drivers/scsi/lpfc/lpfc_attr.c | 3 +++ + drivers/scsi/lpfc/lpfc_els.c | 20 +++++++++++++++++++- + drivers/scsi/lpfc/lpfc_nportdisc.c | 5 +++-- + 4 files changed, 26 insertions(+), 3 deletions(-) + +--- a/drivers/scsi/lpfc/lpfc.h ++++ b/drivers/scsi/lpfc/lpfc.h +@@ -377,6 +377,7 @@ struct lpfc_vport { + #define FC_VPORT_LOGO_RCVD 0x200 /* LOGO received on vport */ + #define FC_RSCN_DISCOVERY 0x400 /* Auth all devices after RSCN */ + #define FC_LOGO_RCVD_DID_CHNG 0x800 /* FDISC on phys port detect DID chng*/ ++#define FC_PT2PT_NO_NVME 0x1000 /* Don't send NVME PRLI */ + #define FC_SCSI_SCAN_TMO 0x4000 /* scsi scan timer running */ + #define FC_ABORT_DISCOVERY 0x8000 /* we want to abort discovery */ + #define FC_NDISC_ACTIVE 0x10000 /* NPort discovery active */ +--- a/drivers/scsi/lpfc/lpfc_attr.c ++++ b/drivers/scsi/lpfc/lpfc_attr.c +@@ -1145,6 +1145,9 @@ lpfc_issue_lip(struct Scsi_Host *shost) + pmboxq->u.mb.mbxCommand = MBX_DOWN_LINK; + pmboxq->u.mb.mbxOwner = OWN_HOST; + ++ if ((vport->fc_flag & FC_PT2PT) && (vport->fc_flag & FC_PT2PT_NO_NVME)) ++ vport->fc_flag &= ~FC_PT2PT_NO_NVME; ++ + mbxstatus = lpfc_sli_issue_mbox_wait(phba, pmboxq, LPFC_MBOX_TMO * 2); + + if ((mbxstatus == MBX_SUCCESS) && +--- a/drivers/scsi/lpfc/lpfc_els.c ++++ b/drivers/scsi/lpfc/lpfc_els.c +@@ -1066,7 +1066,8 @@ stop_rr_fcf_flogi: + + /* FLOGI failed, so there is no fabric */ + spin_lock_irq(shost->host_lock); +- vport->fc_flag &= ~(FC_FABRIC | FC_PUBLIC_LOOP); ++ vport->fc_flag &= ~(FC_FABRIC | FC_PUBLIC_LOOP | ++ FC_PT2PT_NO_NVME); + spin_unlock_irq(shost->host_lock); + + /* If private loop, then allow max outstanding els to be +@@ -3740,6 +3741,23 @@ lpfc_els_retry(struct lpfc_hba *phba, st + /* Added for Vendor specifc support + * Just keep retrying for these Rsn / Exp codes + */ ++ if ((vport->fc_flag & FC_PT2PT) && ++ cmd == ELS_CMD_NVMEPRLI) { ++ switch (stat.un.b.lsRjtRsnCode) { ++ case LSRJT_UNABLE_TPC: ++ case LSRJT_INVALID_CMD: ++ case LSRJT_LOGICAL_ERR: ++ case LSRJT_CMD_UNSUPPORTED: ++ lpfc_printf_vlog(vport, KERN_WARNING, LOG_ELS, ++ "0168 NVME PRLI LS_RJT " ++ "reason %x port doesn't " ++ "support NVME, disabling NVME\n", ++ stat.un.b.lsRjtRsnCode); ++ retry = 0; ++ vport->fc_flag |= FC_PT2PT_NO_NVME; ++ goto out_retry; ++ } ++ } + switch (stat.un.b.lsRjtRsnCode) { + case LSRJT_UNABLE_TPC: + /* The driver has a VALID PLOGI but the rport has +--- a/drivers/scsi/lpfc/lpfc_nportdisc.c ++++ b/drivers/scsi/lpfc/lpfc_nportdisc.c +@@ -1987,8 +1987,9 @@ lpfc_cmpl_reglogin_reglogin_issue(struct + * is configured try it. + */ + ndlp->nlp_fc4_type |= NLP_FC4_FCP; +- if ((vport->cfg_enable_fc4_type == LPFC_ENABLE_BOTH) || +- (vport->cfg_enable_fc4_type == LPFC_ENABLE_NVME)) { ++ if ((!(vport->fc_flag & FC_PT2PT_NO_NVME)) && ++ (vport->cfg_enable_fc4_type == LPFC_ENABLE_BOTH || ++ vport->cfg_enable_fc4_type == LPFC_ENABLE_NVME)) { + ndlp->nlp_fc4_type |= NLP_FC4_NVME; + /* We need to update the localport also */ + lpfc_nvme_update_localport(vport); diff --git a/queue-5.4/series b/queue-5.4/series index a8deac4aa65..eca321c66d4 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -56,6 +56,8 @@ nfs-lookup_directory-is-also-ok-with-symlinks.patch nfs-do-not-report-writeback-errors-in-nfs_getattr.patch mtd-rawnand-qcom-fix-clock-sequencing-in-qcom_nandc_probe.patch mtd-rawnand-brcmnand-fixed-incorrect-sub-page-ecc-status.patch +scsi-lpfc-fix-pt2pt-nvme-prli-reject-logo-loop.patch +edac-fix-calculation-of-returned-address-and-next-offset-in-edac_align_ptr.patch drivers-hv-vmbus-fix-memory-leak-in-vmbus_add_channe.patch kvm-x86-pmu-use-amd64_raw_event_mask-for-perf_type_r.patch arm-omap2-hwmod-add-of_node_put-before-break.patch