- 16 Sep, 2022 11 commits
-
-
James Smart authored
Sometimes VMID targets are not getting rediscovered after a port reset. The iocb is not freed in lpfc_cmpl_ct_cmd_vmid(), which is the completion function for the appid CT commands. So after a port reset, the count of sges is less than the expected count of 250. This causes post reset operation logic to fail and keep the port offline. Fix by freeing the iocb and kref put for the lpfc_cmpl_ct_cmd_vmid() early return cases. Link: https://lore.kernel.org/r/20220911221505.117655-5-jsmart2021@gmail.comCo-developed-by:
Justin Tee <justin.tee@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
James Smart authored
In a situation where the node state changes while a REG_LOGIN is in progress, the LPFC_MBOXQ_t structure is cleared and reused for an UNREG_LOGIN command to release RPI resources without first freeing the mbuf pool resource allocated for REG_LOGIN. Release mbuf pool resource prior to repurposing of the mailbox command structure from REG_LOGIN to UNREG_LOGIN. Link: https://lore.kernel.org/r/20220911221505.117655-4-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
When a FLOGI is received before we have issued our FLOGI, the ACC response to the received FLOGI is issued with SID 2 instead of the expected fabric controller SID. Certain target vendors ignore the malformed ACC with SID 2 and wait for a properly filled ACC with a fabric controller SID. The lpfc_sli_prep_wqe() routine depends on the FC_PT2PT flag to fill in the fabric controller SID when in PT2PT mode, but due to a previous commit the flag was getting cleared. Fix by adding a check for the defer_flogi_acc flag to know whether or not to clear the FC_PT2PT flag on link up. Link: https://lore.kernel.org/r/20220911221505.117655-3-jsmart2021@gmail.com Fixes: 439b9329 ("scsi: lpfc: Fix unsolicited FLOGI receive handling during PT2PT discovery") Co-developed-by:
-
James Smart authored
The if statment check (prli_fc4_req & PRLI_NVME_TYPE) evaluates to true when receiving a PRLI request for bogus FC4 type codes that happen to have the 3rd or 5th bit set because PRLI_NVME_TYPE is 0x28. This leads to sending a PRLI_NVME_ACC even for bogus FC4 type codes. Change the bitwise & check to an exact == type code check to ensure we send PRLI_NVME_ACC only for NVME type coded PRLI requests. Link: https://lore.kernel.org/r/20220911221505.117655-2-jsmart2021@gmail.comCo-developed-by:
-
Dan Carpenter authored
The error code from mpi3mr_post_transport_req() is supposed to be passed to bsg_job_done(job, rc, reslen), but it isn't. Link: https://lore.kernel.org/r/YyMISJzVDARpVwrr@kili Fixes: 176d4aa6 ("scsi: mpi3mr: Support SAS transport class callbacks") Acked-by:
Sathya Prakash Veerichetty <sathya.prakash@broadcom.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
There are three error paths which return success: 1) Propagate the error code from mpi3mr_post_transport_req() if it fails. 2) Return -EINVAL if "ioc_status != MPI3_IOCSTATUS_SUCCESS". 3) Return -EINVAL if "le16_to_cpu(mpi_reply.response_data_length) != sizeof(struct rep_manu_reply)" Link: https://lore.kernel.org/r/YyMIJh1HU2Qz9+Rs@kili Fixes: 2bd37e28 ("scsi: mpi3mr: Add framework to issue MPT transport cmds") Acked-by:
-
Kees Cook authored
ahd_linux_setup_iocell_info() intentionally writes to the const-marked aic79xx_iocell_info array, but is called during __init, so the location is actually writable at this point on most architectures. Annotate this explicitly with __ro_after_init to avoid static analysis confusion. Link: https://lpc.events/event/16/contributions/1175/attachments/1109/2128/2022-LPC-analyzer-talk.pdf Link: https://lore.kernel.org/r/20220914115953.3854029-1-keescook@chromium.org Cc: Hannes Reinecke <hare@suse.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Reported-by:
David Malcolm <dmalcolm@redhat.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Gaosheng Cui authored
se_tmr_req_cache has been removed since commit c8e31f26 ("target: Add SCF_SCSI_TMR_CDB usage and drop se_tmr_req_cache"). Remove extern. Link: https://lore.kernel.org/r/20220913023722.547249-3-cuigaosheng1@huawei.comSigned-off-by:
Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by:
-
Gaosheng Cui authored
qla2x00_get_fw_version_str() has been removed since commit abbd8870 ("[SCSI] qla2xxx: Factor-out ISP specific functions to method-based call tables."). qla2x00_release_nvram_protection() has been removed since commit 459c5378 ("[SCSI] qla2xxx: Add ISP24xx flash-manipulation routines."). qla82xx_rdmem() and qla82xx_wrmem() have been removed since commit 3711333d ("[SCSI] qla2xxx: Updates for ISP82xx."). qla25xx_rd_req_reg(), qla24xx_rd_req_reg(), qla25xx_wrt_rsp_reg(), qla24xx_wrt_rsp_reg(), qla25xx_wrt_req_reg() and qla24xx_wrt_req_reg() have been removed since commit 08029990 ("[SCSI] qla2xxx: Refactor request/response-queue register handling."). qla2x00_async_login_done() has been removed since commit 726b8548 ("qla2xxx: Add framework for async fabric discovery"). qlt_24xx_process_response_error() has been removed since commit c5419e26 ("scsi: qla2xxx: Combine Active command arrays."). Remove the declarations for them from header file. Link: https://lore.kernel.org/r/20220913023722.547249-2-cuigaosheng1@huawei.comSigned-off-by:
-
Dmitry Bogdanov authored
The default target port group is always returned in the list of port groups, even if the behaviour is unwanted, i.e. it has no members and non-default port groups are primary port groups. That violates SPC-4 "6.37 REPORT TARGET PORT GROUPS command": Every target port group shall contain at least one target port. The target port group descriptor shall include one target port descriptor for each target port in the target port group. This patch hides port groups with no ports in REPORT TARGET PORT GROUPS response. Link: https://lore.kernel.org/r/20220912214549.27882-1-d.bogdanov@yadro.comSigned-off-by:
Dmitry Bogdanov <d.bogdanov@yadro.com> Signed-off-by:
-
Dmitry Bogdanov authored
SAM-5 4.8.3 (SCSI target device with multiple SCSI ports structure) obligates to set MULTIP bit when there's multiple SCSI target ports: Each device server shall indicate the presence of multiple SCSI target ports by setting the MULTIP bit to one in its standard INQUIRY data (see SPC-4). Set MULTIP bit automatically to indicate the presence of multiple SCSI target ports within standard inquiry response data if there are multiple target ports in all target port groups of the se_device. Link: https://lore.kernel.org/r/20220912125457.22573-2-d.bogdanov@yadro.comReviewed-by:
Mike Christie <michael.christie@oracle.com> Co-developed-by:
Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by:
-
- 07 Sep, 2022 20 commits
-
-
Colin Ian King authored
There is a spelling mistake in a MODULE_PARM_DESC description. Fix it. Link: https://lore.kernel.org/r/20220906140010.194273-1-colin.i.king@gmail.comSigned-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
John Garry authored
Remote devices may go missing from the per-device nexus reset part of the HA nexus, i.e after the controller reset. This is because libsas may find the devices to be gone as the phy may be temporarily down when processing the bcast event generated from the nexus reset. Filter out bcast events during this time to stop the devices being lost. Link: https://lore.kernel.org/r/1662378529-101489-6-git-send-email-john.garry@huawei.comSigned-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
John Garry authored
Add a helper for bcast processing to reduce duplication. Link: https://lore.kernel.org/r/1662378529-101489-5-git-send-email-john.garry@huawei.comSigned-off-by:
-
John Garry authored
In resetting the controller, SATA devices may be lost. The issue is that when we insert the bcast events to rescan the topology in hisi_sas_rescan_topology(), when we subsequently nexus reset the SATA devices in hisi_sas_async_I_T_nexus_reset(), there is a small timing window in which the remote phy is down and we process the bcast event (meaning that libsas judges that the disk is lost). Ensure that all bcast events are processed prior to the nexus reset to close this window. Link: https://lore.kernel.org/r/1662378529-101489-4-git-send-email-john.garry@huawei.comSigned-off-by:
-
John Garry authored
Once the controller HW has been reset then we can unset flag HISI_SAS_HW_FAULT_BIT. In clearing this flag earlier we can now successfully execute commands in hisi_sas_controller_reset_done(), like bcast processing. Link: https://lore.kernel.org/r/1662378529-101489-3-git-send-email-john.garry@huawei.comSigned-off-by:
-
John Garry authored
Now that libsas and the SCSI core code limits the default sectors from commit 4cbfca5f ("scsi: scsi_transport_sas: cap shost opt_sectors according to DMA optimal limit") and commit 608128d3 ("scsi: sd: allow max_sectors be capped at DMA optimal size limit"), there is no need for the hack to limit the max HW sectors. Link: https://lore.kernel.org/r/1662378529-101489-2-git-send-email-john.garry@huawei.comSigned-off-by:
-
Kees Cook authored
In preparation for FORTIFY_SOURCE performing run-time destination buffer bounds checking for memcpy(), specify the destination output buffer explicitly, instead of asking memcpy() to write past the end of what looked like a fixed-size object. Silences future run-time warning: memcpy: detected field-spanning write (size 80) of single field "trc + 1" (size 64) There is no binary code output differences from this change. Link: https://lore.kernel.org/r/20220901205729.2260982-1-keescook@chromium.org Cc: Bradley Grove <linuxdrivers@attotech.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Letu Ren authored
The original code will "goto out_disable_device" and call pci_disable_device() if pci_enable_device() fails. The kernel will generate a warning message like "3w-9xxx 0000:00:05.0: disabling already-disabled device". We shouldn't disable a device that failed to be enabled. A simple return is fine. Link: https://lore.kernel.org/r/20220829110115.38789-1-fantasquex@gmail.comReported-by:
Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
Letu Ren <fantasquex@gmail.com> Signed-off-by:
-
Daniil Lunev authored
Userspace may want to manually control when the data should go into WriteBooster buffer. The control happens via "wb_on" node, but presently, there is no simple way to check if WriteBooster is supported and enabled. Expose the Write Booster and Clock Scaling capabilities to be able to determine if the Write Booster is available and if its manual control is blocked by Clock Scaling mechanism. Link: https://lore.kernel.org/r/20220829081845.v8.1.Ibf9efc9be50783eeee55befa2270b7d38552354c@changeidReviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Daniil Lunev <dlunev@chromium.org> Signed-off-by:
-
Jack Wang authored
Add missing error check for dma_map_sg(). Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20220826101435.79170-1-jinpu.wang@ionos.comSigned-off-by:
Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
-
Mike Christie authored
The host codes that were supposed to only be used for internal use are now not used, so remove them. Link: https://lore.kernel.org/r/20220812010027.8251-11-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
Don't use: - DID_TARGET_FAILURE - DID_NEXUS_FAILURE - DID_ALLOC_FAILURE - DID_MEDIUM_ERROR Instead use the SCSI midlayer internal values. Link: https://lore.kernel.org/r/20220812010027.8251-10-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If a driver returns: - DID_TARGET_FAILURE - DID_NEXUS_FAILURE - DID_ALLOC_FAILURE - DID_MEDIUM_ERROR we hit a couple bugs: 1. The SCSI error handler runs because scsi_decide_disposition() has no case statements for them and we return FAILED. 2. For SG IO the userspace app gets a success status instead of failed, because scsi_result_to_blk_status() clears those errors. This patch adds a new internal error code byte for use by the SCSI midlayer. This will be used instead of the above error codes, so we don't have to play that clearing the host code game in scsi_result_to_blk_status() and drivers cannot accidentally use them. A subsequent commit will then remove the internal users of the above codes and convert us to use the new ones. Link: https://lore.kernel.org/r/20220812010027.8251-9-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
DID_ALLOC_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. By the code comment, it looks like the driver wanted a retryable error code, so this has it use DID_ERROR. Link: https://lore.kernel.org/r/20220812010027.8251-8-michael.christie@oracle.comSigned-off-by: -
Mike Christie authored
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. This has qla2xxx use DID_NO_CONNECT because it looks like we hit this error when we can't find a port. It will give us the same hard error behavior and it seems to match the error where we can't find the endpoint. Link: https://lore.kernel.org/r/20220812010027.8251-7-michael.christie@oracle.comReviewed-by:Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
-
Mike Christie authored
DID_NEXUS_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. virtio_scsi gets this when something like qemu returns VIRTIO_SCSI_S_NEXUS_FAILURE. It looks like qemu returns that error code if host OS returns DID_NEXUS_FAILURE (qemu's internal SCSI_HOST_RESERVATION_ERROR maps to DID_NEXUS_FAILURE). This shouldn't happen for Linux since we don't propagate that error code to userspace. This has us convert VIRTIO_SCSI_S_NEXUS_FAILURE to a SAM_STAT_RESERVATION_CONFLICT in case some other virt layer is returning it. In that case we will still get the reservation confict failure we expect. Link: https://lore.kernel.org/r/20220812010027.8251-6-michael.christie@oracle.comAcked-by:Paolo Bonzini <pbonzini@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Mike Christie authored
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. virtio_scsi gets this when something like qemu returns VIRTIO_SCSI_S_TARGET_FAILURE. It looks like qemu returns that error code if a host OS returns it, but this shouldn't happen for Linux since we never propagate that error to userspace. This has us use DID_BAD_TARGET in case some other virt layer is returning it. In that case we will still get a hard error like before and it conveys something unexpected happened. Link: https://lore.kernel.org/r/20220812010027.8251-5-michael.christie@oracle.comAcked-by: -
Mike Christie authored
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. It looks like the driver wanted a hard failure so this swaps it with DID_BAD_TARGET which gives us that behavior. The error looks like it's for a case where the target did not support a TMF we wanted to use (maybe not a bad target but disappointing so close enough). Link: https://lore.kernel.org/r/20220812010027.8251-4-michael.christie@oracle.comSigned-off-by: -
Mike Christie authored
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in the SCSI error handling running. It looks like the driver wanted a hard failure so swap it with DID_BAD_TARGET. Link: https://lore.kernel.org/r/20220812010027.8251-3-michael.christie@oracle.comSigned-off-by: -
Mike Christie authored
The error codes: - DID_TARGET_FAILURE - DID_NEXUS_FAILURE - DID_ALLOC_FAILURE - DID_MEDIUM_ERROR are internal to the SCSI layer. Drivers must not use them because: 1. They are not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. xen-scsiback will never see this error and should not try to send it. 2. There is no handling for them in scsi_decide_disposition() so if xen-scsifront were to return the error to the SCSI midlayer then it kicks off the error handler which is definitely not what we want. Remove the use from xen-scsifront/back. Link: https://lore.kernel.org/r/20220812010027.8251-2-michael.christie@oracle.comReviewed-by:Juergen Gross <jgross@suse.com> Signed-off-by:
-
- 01 Sep, 2022 9 commits
-
-
Shaomin Deng authored
There is repeated word, remove it. Link: https://lore.kernel.org/r/20220811153923.17278-1-dengshaomin@cdjrlc.comReviewed-by:
Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by:
Shaomin Deng <dengshaomin@cdjrlc.com> Signed-off-by:
-
Christophe JAILLET authored
{clear|set}_bit() can take an almost arbitrarily large bit number, so there is no need to manually compute addresses. This is just redundant. Link: https://lore.kernel.org/r/c3429a22023f58e5e5cc65d6cd7e83fb2bd9b870.1658340442.git.christophe.jaillet@wanadoo.frTested-by:Don Brace <don.brace@microchip.com> Acked-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
Use bitmap_zalloc()/bitmap_free() instead of hand-writing them. It is less verbose and it improves the semantic. Link: https://lore.kernel.org/r/5f975ef43f8b7306e4ac4e2e8ce4bcd53f6092bb.1658340441.git.christophe.jaillet@wanadoo.frTested-by:
-
ye xingchen authored
Return the value from lpfc_issue_reg_vfi() directly instead of storing it in another redundant variable. Link: https://lore.kernel.org/r/20220824075123.221316-1-ye.xingchen@zte.com.cnReported-by:
Zeal Robot <zealci@zte.com.cn> Reviewed-by:
ye xingchen <ye.xingchen@zte.com.cn> Signed-off-by:
-
ye xingchen authored
Return the value from lpfc_sli4_issue_wqe() directly instead of storing it in another redundant variable. Link: https://lore.kernel.org/r/20220824075017.221244-1-ye.xingchen@zte.com.cnReported-by:
-
Randy Dunlap authored
Correct a typo in SCSI documentation. Link: https://lore.kernel.org/r/20220827221719.11006-1-rdunlap@infradead.org Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Nilesh Javali authored
Link: https://lore.kernel.org/r/20220826102559.17474-8-njavali@marvell.comReviewed-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
-
Nilesh Javali authored
drivers/scsi/qla2xxx/qla_os.c:40:20: warning: symbol 'qla_trc_array' was not declared. Should it be static? drivers/scsi/qla2xxx/qla_os.c:345:5: warning: symbol 'ql2xdelay_before_pci_error_handling' was not declared. Should it be static? Define qla_trc_array and ql2xdelay_before_pci_error_handling as static to fix sparse warnings. Link: https://lore.kernel.org/r/20220826102559.17474-7-njavali@marvell.com Cc: stable@vger.kernel.org Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Arun Easi authored
Older tracing of driver messages was to: - log only debug messages to kernel main trace buffer; and - log only if extended logging bits corresponding to this message is off This has been modified and extended as follows: - Tracing is now controlled via ql2xextended_error_logging_ktrace module parameter. Bit usages same as ql2xextended_error_logging. - Tracing uses "qla2xxx" trace instance, unless instance creation have issues. - Tracing is enabled (compile time tunable). - All driver messages, include debug and log messages are now traced in kernel trace buffer. Trace messages can be viewed by looking at the qla2xxx instance at: /sys/kernel/tracing/instances/qla2xxx/trace Trace tunable that takes the same bit mask as ql2xextended_error_logging is: ql2xextended_error_logging_ktrace (default=1) Link: https://lore.kernel.org/r/20220826102559.17474-6-njavali@marvell.comSuggested-by:Daniel Wagner <dwagner@suse.de> Suggested-by:
Steven Rostedt <rostedt@goodmis.org> Tested-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
-
