kernel/drivers/scsi/lpfc, branch linux-5.1.y

scsi: lpfc: add check for loss of ndlp when sending RRQ

2019-06-19T06:00:07Z

[ Upstream commit c8cb261a072c88ca1aff0e804a30db4c7606521b ] There was a missing qualification of a valid ndlp structure when calling to send an RRQ for an abort. Add the check. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Tested-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: correct rcu unlock issue in lpfc_nvme_info_show

2019-06-19T06:00:07Z

[ Upstream commit 79080d349f7f58a2e86c56043a3d04184d5f294a ] Many of the exit cases were not releasing the rcu read lock. Corrected the exit paths. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Tested-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: resolve lockdep warnings

2019-06-19T06:00:07Z

[ Upstream commit e2a8be5696e706a2fce6edd11e5c74ce14cffec0 ] There were a number of erroneous comments and incorrect older lockdep checks that were causing a number of warnings. Resolve the following: - Inconsistent lock state warnings in lpfc_nvme_info_show(). - Fixed comments and code on sequences where ring lock is now held instead of hbalock. - Reworked calling sequences around lpfc_sli_iocbq_lookup(). Rather than locking prior to the routine and have routine guess on what lock, take the lock within the routine. The lockdep check becomes unnecessary. - Fixed comments and removed erroneous hbalock checks. Signed-off-by: Dick Kennedy Signed-off-by: James Smart CC: Bart Van Assche Tested-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: Fix use-after-free mailbox cmd completion

2019-05-31T13:43:55Z

[ Upstream commit 9b1640686470fbbd1c6efb35ada6fe1427ea8d0f ] When unloading the driver, mailbox commands may be sent without holding a reference on the ndlp. By the time the mailbox command completes, the ndlp may have reduced its ref counts and been freed. The problem was reported by KASAN. While unregistering due to driver unload, have the completion noop'd by setting the ndlp context NULL'd. Due to the unload, no further action was necessary. Also, while reviewing this path, the generic nulling of the context after handling should be slightly moved. Reported by: Bart Van Assche Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: Resolve irq-unsafe lockdep heirarchy warning in lpfc_io_free

2019-05-31T13:43:55Z

[ Upstream commit 50e3f871fb20a9bb644743e2986e8f50f98a25bc ] A patch in the 12.2.0.0 set caused a new lockdep warning: WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 5.0.0-rc8-next-20190301-dbg+ #1 Not tainted Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&qp->io_buf_list_put_lock)->rlock); local_irq_disable(); lock(&(&phba->hbalock)->rlock); lock(&(&qp->io_buf_list_put_lock)->rlock); lock(&(&phba->hbalock)->rlock); see: https://www.spinics.net/lists/linux-scsi/msg128389.html In summary, the new patch added taking the io_buf_list_put_lock while under an irq-disabled hbalock. This created a lock heirarchy dependent upon irq being disabled, and there are paths that take the io_buf_list_put_lock without disabling irq. Looking at the lpfc_io_free routine, which is where the new heirarchy was introduced, there is no reason to be taking out the hbalock and raising irq, as the functionality is replaced by the io_buf_list_xxx locks. Resolve by removing the hbalock/irq calls in lpfc_io_free. Fixes: 5e5b511d8bfa ("scsi: lpfc: Partition XRI buffer list across Hardware Queues") Reported-by: Bart Van Assche Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: Resolve inconsistent check of hdwq in lpfc_scsi_cmd_iocb_cmpl

2019-05-31T13:43:55Z

[ Upstream commit ff6bf89717b0dc7b8dd0934d1c065f29069831e7 ] A prior patch which added support for non-uniform allocation of MSIX vectors now causes a smatch complaint: drivers/scsi/lpfc/lpfc_scsi.c:3674 lpfc_scsi_cmd_iocb_cmpl() error: we previously assumed 'phba->sli4_hba.hdwq' could be null (see line 3667) Resolve by removing the unnecessary check for a NULL hdwq table. Fixes 6a828b0f6192: ("scsi: lpfc: Support non-uniform allocation of MSIX vectors to hardware queues") Reported-by: Dan Carpenter Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: Fix mailbox hang on adapter init

2019-05-31T13:43:54Z

[ Upstream commit e8869f5b0a7273fcf20ef99066fd8129e58ba5b7 ] The adapter initialization sequence enables interrupts, initializes the adapter link_state to LINK_DOWN, then issues commands to initialize the adapter. The interrupt handler on the adapter validates the link_state (has to be at least LINK_DOWN) and if invalid, will discard the interrupting event. In most cases, there is not a command completion, thus an interrupt until the initialization commands have been sent which is post the setting of state to LINK_DOWN. However, in cases of firmware reset, the reset will modify the link_state to an invalid value (indicating a reset of the adapter) and there occasionally are cases where the adapter will generate an asynchronous event which shares the eq/cq used for mailbox commands. In the failure case, an interrupt is generated immediately after enabling them due to the async event. As link_state is invalid, the eq is list and the CQ not serviced. At this point link_state is initialized and the mailbox command sent. As the CQ has not been serviced, it is not armed, so no interrupt event is generated when the mailbox command completes. Modify the initialization sequence so that interrupts are enabled after link_state is properly initialized, which avoids the race condition with the async event. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: Fix SLI3 commands being issued on SLI4 devices

2019-05-31T13:43:54Z

[ Upstream commit c95a3b4b0fb8d351e2329a96f87c4fc96a149505 ] During debug, it was seen that the driver is issuing commands specific to SLI3 on SLI4 devices. Although the adapter correctly rejected the command, this should not be done. Revise the code to stop sending these commands on a SLI4 adapter. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: Fix io lost on host resets

2019-05-31T13:43:54Z

[ Upstream commit c66a91974634bfdf9d8e8736219d3b27621fa704 ] If the driver undergoes repeated host resets it starts losing exchange structures and eventually returns SCSI_MLQUEUE_HOST_BUSY and does not recover. The offline path is not reclaiming the outstanding ios on the fcp pring txcmplq before calling lpfc_destroy_multixripool, which causes the txmcplq to be reinit and the resources lost. Flush the fcp rings before destroying the multixripools. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: Fix fc4type information for FDMI

2019-05-31T13:43:54Z

[ Upstream commit 32a80c093b524a0682f1c6166c910387b116ffce ] The driver is reporting support for NVME even when not configured for NVME operation. Fix (and make more readable) when NVME protocol support is indicated. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin