- 27 Apr, 2021 2 commits
-
-
James Smart authored
lpfc_bsg_ct_unsol_event() routine acts assigns a ct_request to the wrong structure address, resulting in a bad address that results in bsg related timeouts. Correct the ct_request assignment to use the kernel virtual buffer address (not the control structure address). Link: https://lore.kernel.org/r/20210421234448.102132-1-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 devloss timer handler and in backend calls to terminate remote port I/O, there is logic to walk through all active IOCBs and validate them to potentially trigger an abort request. This logic is causing illegal memory accesses which leads to a crash. Abort IOCBs, which may be on the list, do not have an associated lpfc_io_buf struct. The driver is trying to map an lpfc_io_buf struct on the IOCB and which results in a bogus address thus the issue. Fix by skipping over ABORT IOCBs (CLOSE IOCBs are ABORTS that don't send ABTS) in the IOCB scan logic. Link: https://lore.kernel.org/r/20210421234433.102079-1-jsmart2021@gmail.comCo-developed-by:
-
- 22 Apr, 2021 1 commit
-
-
Ming Lei authored
Fixes the following warning when running 'make htmldocs': include/linux/blk-mq.h:395: warning: Function parameter or member 'set_rq_budget_token' not described in 'blk_mq_ops' include/linux/blk-mq.h:395: warning: Function parameter or member 'get_rq_budget_token' not described in 'blk_mq_ops' [mkp: added warning messages] Link: https://lore.kernel.org/r/20210421154526.1954174-1-ming.lei@redhat.com Fixes: d022d18c ("scsi: blk-mq: Add callbacks for storing & retrieving budget token") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
-
- 16 Apr, 2021 37 commits
-
-
Bart Van Assche authored
Fix the function name in the kernel-doc header above ft_prli(). Link: https://lore.kernel.org/r/20210415220826.29438-21-bvanassche@acm.org Cc: Hannes Reinecke <hare@suse.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Bart Van Assche authored
Do not print tg_pt_gp->tg_pt_gp_valid_id if we already know that it is zero. Link: https://lore.kernel.org/r/20210415220826.29438-20-bvanassche@acm.org Cc: Mike Christie <michael.christie@oracle.com> Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
-
Bart Van Assche authored
Use format specifier '%u' to format the u32 data type instead of '%hu'. Link: https://lore.kernel.org/r/20210415220826.29438-19-bvanassche@acm.org Cc: Mike Christie <michael.christie@oracle.com> Reviewed-by:
-
Bart Van Assche authored
Instead of leaving it implicit that SAM_STAT_GOOD == 0, compare explicitly with SAM_STAT_GOOD. Link: https://lore.kernel.org/r/20210415220826.29438-18-bvanassche@acm.orgReviewed-by:
-
Bart Van Assche authored
Instead of using 'retval' to represent first a SCSI status and later whether or not a disk change event occurred, introduce a new variable for the latter purpose. Link: https://lore.kernel.org/r/20210415220826.29438-17-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Daniel Wagner <dwagner@suse.de> Signed-off-by:
-
Bart Van Assche authored
The dc395x driver is one of the two drivers that passes an u8 argument to status_byte() instead of an s32 argument. Open-code status_byte() in preparation of changing SCSI status values into a structure. Link: https://lore.kernel.org/r/20210415220826.29438-16-bvanassche@acm.org Cc: Hannes Reinecke <hare@suse.com> Signed-off-by:
-
Bart Van Assche authored
The 53c700 driver is one of the two drivers that passes an u8 argument to status_byte() instead of an s32 argument. Open-code status_byte in preparation of changing SCSI status values into a structure. Link: https://lore.kernel.org/r/20210415220826.29438-15-bvanassche@acm.org Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Bart Van Assche authored
This was detected by building the kernel with clang and W=1. Link: https://lore.kernel.org/r/20210415220826.29438-14-bvanassche@acm.org Cc: Don Brace <don.brace@microchip.com> Signed-off-by:
-
Bart Van Assche authored
This was detected by building the kernel with clang and W=1. Link: https://lore.kernel.org/r/20210415220826.29438-13-bvanassche@acm.org Cc: Nilesh Javali <njavali@marvell.com> Acked-by:
Manish Rangankar <mrangankar@marvell.com> Signed-off-by:
-
Bart Van Assche authored
This was detected by building the kernel with clang and W=1. Link: https://lore.kernel.org/r/20210415220826.29438-12-bvanassche@acm.org Cc: Hannes Reinecke <hare@kernel.org> Signed-off-by:
-
Bart Van Assche authored
This was detected by building the kernel with clang and W=1. Link: https://lore.kernel.org/r/20210415220826.29438-11-bvanassche@acm.org Cc: Hannes Reinecke <hare@kernel.org> Signed-off-by:
-
Bart Van Assche authored
Fix the following warnings: drivers/scsi/mpt3sas/mpt3sas_base.c:5430: warning: Excess function parameter 'ct' description in '_base_allocate_pcie_sgl_pool' drivers/scsi/mpt3sas/mpt3sas_base.c:5493: warning: Excess function parameter 'ctr' description in '_base_allocate_chain_dma_pool' Link: https://lore.kernel.org/r/20210415220826.29438-10-bvanassche@acm.org Fixes: d6adc251 ("scsi: mpt3sas: Force PCIe scatterlist allocations to be within same 4 GB region") Fixes: 7dd847da ("scsi: mpt3sas: Force chain buffer allocations to be within same 4 GB region") Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Bart Van Assche authored
Suppress the following compiler warning: warning: cast to smaller integer type 'enum fip_mode' from 'void *' [-Wvoid-pointer-to-enum-cast] enum fip_mode fip_mode = (enum fip_mode)kp->arg; ^~~~~~~~~~~~~~~~~~~~~~ Link: https://lore.kernel.org/r/20210415220826.29438-9-bvanassche@acm.org Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: -
Bart Van Assche authored
Since the 'mfs' member has been declared as 'u32' in include/scsi/libfc.h, use the %u format specifier instead of %hu. This patch fixes the following clang compiler warning: warning: format specifies type 'unsigned short' but the argument has type 'u32' (aka 'unsigned int') [-Wformat] "lport->mfs:%hu\n", mfs, lport->mfs); ~~~ ^~~~~~~~~~ %u Link: https://lore.kernel.org/r/20210415220826.29438-8-bvanassche@acm.org Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: -
Bart Van Assche authored
This was detected by building the kernel with clang and W=1. Link: https://lore.kernel.org/r/20210415220826.29438-7-bvanassche@acm.org Cc: aacraid@microsemi.com Signed-off-by:
-
Bart Van Assche authored
Improve readability of the code in the SCSI core by introducing an enumeration type for the values used internally that decide how to continue processing a SCSI command. The eh_*_handler return values have not been changed because that would involve modifying all SCSI drivers. The output of the following command has been inspected to verify that no out-of-range values are assigned to a variable of type enum scsi_disposition: KCFLAGS=-Wassign-enum make CC=clang W=1 drivers/scsi/ Link: https://lore.kernel.org/r/20210415220826.29438-6-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Daniel Wagner <dwagner@suse.de> Signed-off-by:
-
Bart Van Assche authored
The comment above scsi_send_eh_cmnd() says: "Returns SUCCESS or FAILED or NEEDS_RETRY". This patch makes all values returned by scsi_send_eh_cmnd() match the documentation of this function. This change does not affect the behavior of scsi_eh_tur() nor of scsi_eh_try_stu() nor of the scsi_request_sense() callers. See also commit bbe9fb0d ("scsi: Avoid that .queuecommand() gets called for a blocked SCSI device"; v5.3). Link: https://lore.kernel.org/r/20210415220826.29438-5-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Daniel Wagner <dwagner@suse.de> Signed-off-by:
-
Bart Van Assche authored
Commit 320ae51f ("blk-mq: new multi-queue block IO queueing mechanism"; v3.13) introduced a code path that calls the blk-mq completion function from interrupt context. scsi-mq was introduced by commit d285203c ("scsi: add support for a blk-mq based I/O path."; v3.17). Since the introduction of scsi-mq, scsi_softirq_done() can be called from interrupt context. That made the name of the function misleading, rename it to scsi_complete(). Link: https://lore.kernel.org/r/20210415220826.29438-4-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Daniel Wagner <dwagner@suse.de> Signed-off-by:
-
Bart Van Assche authored
scsi_device.sdev_target is used in more code than the single_lun code, hence remove the comment next to the definition of the sdev_target member. Link: https://lore.kernel.org/r/20210415220826.29438-3-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Daniel Wagner <dwagner@suse.de> Signed-off-by:
-
Bart Van Assche authored
The current scsi_alloc_sgtables() documentation does not accurately explain what this function does. Hence improve the documentation of this function. Link: https://lore.kernel.org/r/20210415220826.29438-2-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Daniel Wagner <dwagner@suse.de> Signed-off-by:
-
Viswas G authored
Introduce spin lock for outbound queue. With this, driver need not acquire HBA global lock for outbound queue processing. Link: https://lore.kernel.org/r/20210415103352.3580-9-Viswas.G@microchip.comAcked-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
Viswas G <Viswas.G@microchip.com> Signed-off-by:
Ruksar Devadi <Ruksar.devadi@microchip.com> Signed-off-by:
Ashokkumar N <Ashokkumar.N@microchip.com> Signed-off-by:
-
Viswas G authored
Producer index(PI) outbound queue and consumer index(CI) for Outbound queue are in DMA memory. During resume(), the stale PI and CI Values will lead to unexpected behavior. These values should be reset to 0 during driver reinitialization. Link: https://lore.kernel.org/r/20210415103352.3580-8-Viswas.G@microchip.comAcked-by:
-
Ruksar Devadi authored
When controller runs into fatal error, I/Os get stuck with no response, handler event is defined to complete the pending I/Os (SAS task and internal task) and also perform the cleanup for the drives. Link: https://lore.kernel.org/r/20210415103352.3580-7-Viswas.G@microchip.comAcked-by:
-
Vishakha Channapattan authored
A new sysfs variable 'ctl_iop1_count' is being introduced that tells if the controller is alive by indicating controller ticks. If on subsequent run we see the ticks changing that indicates that controller is not dead. Using the 'ctl_iop1_count' sysfs variable we can see ticks incrementing: linux-9saw:~# cat /sys/class/scsi_host/host*/ctl_iop1_count 0x00000069 0x0000006b 0x0000006d 0x00000072 Link: https://lore.kernel.org/r/20210415103352.3580-6-Viswas.G@microchip.comAcked-by:Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
Vishakha Channapattan <vishakhavc@google.com> Signed-off-by:
Radha Ramachandran <radha@google.com> Signed-off-by:
-
Vishakha Channapattan authored
A new sysfs variable 'ctl_iop0_count' is being introduced that tells if the controller is alive by indicating controller ticks. If on subsequent run we see the ticks changing that indicates that controller is not dead. Using the 'ctl_iop0_count' sysfs variable we can see ticks incrementing: linux-9saw:~# cat /sys/class/scsi_host/host*/ctl_iop0_count 0x000000a3 0x000001db 0x000001e4 0x000001e7 Link: https://lore.kernel.org/r/20210415103352.3580-5-Viswas.G@microchip.comAcked-by: -
Vishakha Channapattan authored
A new sysfs variable 'ctl_raae_count' is being introduced that tells if the controller is alive by indicating controller ticks. If on subsequent run we see the ticks changing in RAAE count that indicates that controller is not dead. Using the 'ctl_raae_count' sysfs variable we can see ticks incrementing: linux-9saw:~# cat /sys/class/scsi_host/host*/ctl_raae_count 0x00002245 0x00002253 0x0000225e Link: https://lore.kernel.org/r/20210415103352.3580-4-Viswas.G@microchip.comAcked-by: -
Vishakha Channapattan authored
A new sysfs variable 'ctl_hmi_error' is being introduced to give the error details if the MPI initialization fails Using the 'ctl_hmi_error' sysfs variable we can check the error details: linux-2dq0:~# cat /sys/class/scsi_host/host*/ctl_hmi_error 0x00000000 0x00000000 0x00000000 Link: https://lore.kernel.org/r/20210415103352.3580-3-Viswas.G@microchip.comSigned-off-by: -
Vishakha Channapattan authored
A new sysfs variable 'ctl_mpi_state' is being introduced to check the state of MPI. Using the 'ctl_mpi_state' sysfs variable we can check the MPI state: linux-2dq0:~# cat /sys/class/scsi_host/host*/ctl_mpi_state MPI is successfully initialized Link: https://lore.kernel.org/r/20210415103352.3580-2-Viswas.G@microchip.comReported-by:kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Julian Wiedmann authored
The qdio layer currently provides its own infrastructure to scan for Request Queue completions & to report them to the device driver. This comes with several drawbacks - having an async tasklet & timer construct in qdio introduces additional lifetime complexity, and makes it harder to integrate them with the rest of the device driver. The timeouts are also currently hard-coded, and can't be tweaked without affecting other qdio drivers (ie. qeth). But due to recent enhancements to the qdio layer, zfcp can actually take full control of the Request Queue completion processing. It merely needs to opt-out from the qdio layer mechanisms by setting the scan_threshold to 0, and then use qdio_inspect_queue() to scan for completions. So re-implement the tasklet & timer mechanism in zfcp, while initially copying the scan conditions from qdio's handle_outbound() and qdio_outbound_tasklet(). One minor behavioural change is that zfcp_qdio_send() will unconditionally reduce the timeout to 1 HZ, rather than leaving it at 10 Hz if it was last armed by the tasklet. This just makes things more consistent. Also note that we can drop a lot of the accumulated cruft in qdio_outbound_tasklet(), as zfcp doesn't even use PCI interrupt requests any longer. This also slightly touches the Response Queue processing, as qdio_get_next_buffers() will no longer implicitly scan for Request Queue completions. So complete the migration to qdio_inspect_queue() here as well and make the tasklet_schedule() visible. Link: https://lore.kernel.org/r/018d3ddd029f8d6ac00cf4184880288c637c4fd1.1618417667.git.bblock@linux.ibm.comReviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
-
Qinglang Miao authored
Place the put_device() call after device_unregister() in both zfcp_unit_remove() and zfcp_sysfs_port_remove_store() to make it more natural. put_device() ought to be the last time we touch the object in both functions. Add comments after put_device() to make code clearer. Link: https://lore.kernel.org/r/0a568c7733ba0f1dde28b0c663b90270d44dd540.1618417667.git.bblock@linux.ibm.comSuggested-by:
Steffen Maier <maier@linux.ibm.com> Suggested-by:
Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by:
-
Julian Wiedmann authored
The error path from zfcp_adapter_enqueue() no longer attempts to remove the diagnostics attributes if they haven't been created yet. So remove the manual 'sysfs_established' guard for this case, and use device_add_groups() to add all adapter-related sysfs attributes in one go. Link: https://lore.kernel.org/r/37a97537f675d643006271f37723c346189b6eec.1618417667.git.bblock@linux.ibm.comReviewed-by:
-
Julian Wiedmann authored
When zfcp_adapter_enqueue() fails to create the zfcp_sysfs_adapter_attrs group, it calls zfcp_adapter_unregister() to tear down the adapter state again. This then unconditionally attempts to remove the zfcp_sysfs_adapter_attrs group, resulting in a "group not found" WARN from sysfs code. Avoid this by copying most of zfcp_adapter_unregister() into the error path, allowing for more fine-granular roll-back. Then skip the sysfs tear-down steps if we haven't progressed this far in the initialization. Link: https://lore.kernel.org/r/790922cc3af075795fff9a4b787e6bda19bdb3be.1618417667.git.bblock@linux.ibm.comReviewed-by:
-
Yevhen Viktorov authored
Code indentation should use tabs where possible. Link: https://lore.kernel.org/r/e8a15a2f3d64e2e76a214647cfd4fe23d370b165.1618417667.git.bblock@linux.ibm.comSigned-off-by:
Yevhen Viktorov <yevhen.viktorov@virginmedia.com> Signed-off-by:
-
Julian Wiedmann authored
INIT_LIST_HEAD() is only needed for actual list heads, while req->list is used as a list entry. Note that when the error path in zfcp_fsf_req_send() removes the request from the adapter's list of pending requests, it actually looks up the request from the zfcp_reqlist - rather than just calling list_del(). So there's no risk of us calling list_del() on a request that hasn't been added to any list yet. Link: https://lore.kernel.org/r/254dc0ae28dccc43ab0b1079ef2c8dcb5fe1d2e4.1618417667.git.bblock@linux.ibm.comReviewed-by:
-
Roman Bolshakov authored
Commit a6dcfe08 ("scsi: qla2xxx: Limit interrupt vectors to number of CPUs") lowers the number of allocated MSI-X vectors to the number of CPUs. That breaks vector allocation assumptions in qla83xx_iospace_config(), qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions computes maximum number of qpairs as: ha->max_qpairs = ha->msix_count - 1 (MB interrupt) - 1 (default response queue) - 1 (ATIO, in dual or pure target mode) max_qpairs is set to zero in case of two CPUs and initiator mode. The number is then used to allocate ha->queue_pair_map inside qla2x00_alloc_queues(). No allocation happens and ha->queue_pair_map is left NULL but the driver thinks there are queue pairs available. qla2xxx_queuecommand() tries to find a qpair in the map and crashes: if (ha->mqenable) { uint32_t tag; uint16_t hwq; struct qla_qpair *qpair = NULL; tag = blk_mq_unique_tag(cmd->request); hwq = blk_mq_unique_tag_to_hwq(tag); qpair = ha->queue_pair_map[hwq]; # <- HERE if (qpair) return qla2xxx_mqueuecommand(host, cmd, qpair); } BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc] RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx] Call Trace: scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0 ? __sbitmap_get_word+0x2a/0x80 __blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_sched_dispatch_requests+0x2b/0x50 __blk_mq_run_hw_queue+0x49/0xb0 __blk_mq_delay_run_hw_queue+0xfb/0x150 blk_mq_sched_insert_request+0xbe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250 scsi_probe_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620 ? __pm_runtime_resume+0x4f/0x70 scsi_scan_target+0x100/0x110 fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc] process_one_work+0x1ea/0x3b0 worker_thread+0x28/0x3b0 ? process_one_work+0x3b0/0x3b0 kthread+0x112/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 The driver should allocate enough vectors to provide every CPU it's own HW queue and still handle reserved (MB, RSP, ATIO) interrupts. The change fixes the crash on dual core VM and prevents unbalanced QP allocation where nr_hw_queues is two less than the number of CPUs. Link: https://lore.kernel.org/r/20210412165740.39318-1-r.bolshakov@yadro.com Fixes: a6dcfe08 ("scsi: qla2xxx: Limit interrupt vectors to number of CPUs") Cc: Daniel Wagner <daniel.wagner@suse.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Nilesh Javali <njavali@marvell.com> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: stable@vger.kernel.org # 5.11+ Reported-by:
Aleksandr Volkov <a.y.volkov@yadro.com> Reported-by:
Aleksandr Miloserdov <a.miloserdov@yadro.com> Reviewed-by:
Daniel Wagner <dwagner@suse.de> Reviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by:
-
Don Brace authored
Dan Carpenter found a possible NULL pointer dereference issue in function pqi_sas_port_add_rphy(): drivers/scsi/smartpqi/smartpqi_sas_transport.c:97 pqi_sas_port_add_rphy() warn: variable dereferenced before check 'pqi_sas_port->device' (see line 95) Correct issue by moving reference of pqi_sas_port->device after the check for the device pointer being non-NULL. Link: https://www.mail-archive.com/kbuild@lists.01.org/msg06329.html Link: https://lore.kernel.org/r/161850493026.7302.10032784239320437353.stgit@brunhilda Fixes: ec504b23 ("scsi: smartpqi: Add phy ID support for the physical drives") Reported-by:
Scott Benesh <scott.benesh@microchip.com> Reviewed-by:
Scott Teel <scott.teel@microchip.com> Reviewed-by:
Mike McGowen <mike.mcgowen@microchip.com> Reviewed-by:
Kevin Barnett <kevin.barnett@microchip.com> Signed-off-by:
Don Brace <don.brace@microchip.com> Signed-off-by:
-
Don Brace authored
Dan Carpenter found a possible divide by 0 issue in the smartpqi driver in functions pci_get_aio_common_raid_map_values() and pqi_calc_aio_r5_or_r6(). The variable rmd->blocks_per_row is used as a divisor and could be 0. Using rmd->blocks_per_row as a divisor without checking it for 0 first. Correct these possible divide by 0 conditions by insuring that rmd->blocks_per_row is not zero before usage. The check for non-0 was too late to prevent a divide by 0 condition. Add in a comment to explain why the check for non-zero is necessary. If the member is 0, return PQI_RAID_BYPASS_INELIGIBLE before any division is performed. Link: https://lore.kernel.org/linux-scsi/YG%2F5kWHHAr7w5dU5@mwanda/ Link: https://lore.kernel.org/r/161850492435.7302.392780350442938047.stgit@brunhilda Fixes: 6702d2c4 ("scsi: smartpqi: Add support for RAID5 and RAID6 writes") Reported-by:
-
