- Nov 13, 2019
-
-
Bean Huo authored
Print out returned response size and buffer size, while the front one is bigger than the back one. Link: https://lore.kernel.org/r/20191112223436.27449-2-huobean@gmail.com Reviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
John Garry authored
The !! operator on a bool is pointless, so remove an example in hisi_sas_rescan_topology(). Link: https://lore.kernel.org/r/1573551059-107873-5-git-send-email-john.garry@huawei.com Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Xiang Chen authored
Currently we call function hisi_sas_debugfs_exit() to remove debugfs_dir before freeing interrupt irqs and destroying workqueue in the driver remove path. If a dump is triggered before function hisi_sas_debugfs_exit() but debugfs_work may be called after it, so it may refer to already removed debugfs_dir which will cause NULL pointer dereference. To avoid it, put function hisi_sas_debugfs_exit() after free_irqs and destroy workqueue when removing hisi_sas driver. Link: https://lore.kernel.org/r/1573551059-107873-4-git-send-email-john.garry@huawei.com Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
Xiang Chen authored
Need to return directly if init hardware failed. Fixes: 73a4925d ("scsi: hisi_sas: Update all the registers after suspend and resume") Link: https://lore.kernel.org/r/1573551059-107873-3-git-send-email-john.garry@huawei.com Signed-off-by:
-
Xiang Chen authored
Need to check the structure sas_port before using it. Link: https://lore.kernel.org/r/1573551059-107873-2-git-send-email-john.garry@huawei.com Signed-off-by:
-
James Smart authored
Update lpfc version to 12.6.0.2 Link: https://lore.kernel.org/r/20191111230401.12958-7-jsmart2021@gmail.com Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
James Smart authored
Driver is setting the initiator nvme template with a max hw queues value of the present cpu count which is odd. It should be registering the number of hdwq queues (queues created on the adapter). Change to set nvme tempate, in all cases, to the number of hardware queues. Link: https://lore.kernel.org/r/20191111230401.12958-6-jsmart2021@gmail.com Signed-off-by:
-
James Smart authored
Currently, cpu_map[cpu#]->hdwq is left to equal LPFC_VECTOR_MAP_EMPTY for not present CPUs. If a CPU is dynamically hot-added, it is possible we may crash due to not assigning an allocated hdwq. Correct by assigning a hdwq at initialization for all not-present CPUs. Fixes: dcaa2136 ("scsi: lpfc: Change default IRQ model on AMD architectures") Link: https://lore.kernel.org/r/20191111230401.12958-5-jsmart2021@gmail.com Reviewed-by:
-
James Smart authored
Compilation can fail due to having an inline function reference where the function body is not present. Fix by removing the inline tag. Fixes: 93a4d6f4 ("scsi: lpfc: Add registration for CPU Offline/Online events") Link: https://lore.kernel.org/r/20191111230401.12958-4-jsmart2021@gmail.com Reviewed-by:
-
James Smart authored
Coverity reported the following: *** CID 101747: Null pointer dereferences (FORWARD_NULL) /drivers/scsi/lpfc/lpfc_els.c: 4439 in lpfc_cmpl_els_rsp() 4433 kfree(mp); 4434 } 4435 mempool_free(mbox, phba->mbox_mem_pool); 4436 } 4437 out: 4438 if (ndlp && NLP_CHK_NODE_ACT(ndlp)) { vvv CID 101747: Null pointer dereferences (FORWARD_NULL) vvv Dereferencing null pointer "shost". 4439 spin_lock_irq(shost->host_lock); 4440 ndlp->nlp_flag &= ~(NLP_ACC_REGLOGIN | NLP_RM_DFLT_RPI); 4441 spin_unlock_irq(shost->host_lock); 4442 4443 /* If the node is not being used by another discovery thread, 4444 * and we are sending a reject, we are done with it. Fix by adding a check for non-null shost in line 4438. The scenario when shost is set to null is when ndlp is null. As such, the ndlp check present was sufficient. But better safe than sorry so add the shost check. Reported-by:coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 101747 ("Null pointer dereferences") Fixes: 2e0fef85 ("[SCSI] lpfc: NPIV: split ports") CC: James Bottomley <James.Bottomley@SteelEye.com> CC: "Gustavo A. R. Silva" <gustavo@embeddedor.com> CC: linux-next@vger.kernel.org Link: https://lore.kernel.org/r/20191111230401.12958-3-jsmart2021@gmail.com Reviewed-by:
-
James Smart authored
Coverity reported the following: *** CID 1487391: Null pointer dereferences (FORWARD_NULL) /drivers/scsi/lpfc/lpfc_scsi.c: 614 in lpfc_get_scsi_buf_s3() 608 spin_unlock(&phba->scsi_buf_list_put_lock); 609 } 610 spin_unlock_irqrestore(&phba->scsi_buf_list_get_lock, iflag); 611 612 if (lpfc_ndlp_check_qdepth(phba, ndlp)) { 613 atomic_inc(&ndlp->cmd_pending); vvv CID 1487391: Null pointer dereferences (FORWARD_NULL) vvv Dereferencing null pointer "lpfc_cmd". 614 lpfc_cmd->flags |= LPFC_SBUF_BUMP_QDEPTH; 615 } 616 return lpfc_cmd; 617 } 618 /** 619 * lpfc_get_scsi_buf_s4 - Get a scsi buffer from io_buf_list of the HBA Fix by checking lpfc_cmd to be non-NULL as part of line 612 Reported-by: -
Vignesh Raghavendra authored
TI's J721e SoC has a Cadence UFS IP with a TI specific wrapper. This is a minimal driver to configure the wrapper. It releases the UFS slave device out of reset and sets up registers to indicate PHY reference clock input frequency before probing child Cadence UFS driver. Link: https://lore.kernel.org/r/20191108164857.11466-3-vigneshr@ti.com Reviewed-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
-
Vignesh Raghavendra authored
Add binding documentation of TI wrapper for Cadence UFS Controller. Link: https://lore.kernel.org/r/20191108164857.11466-2-vigneshr@ti.com Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- Nov 09, 2019
-
-
Damien Le Moal authored
Prevent recursion into the IO path under low memory conditions by using GFP_NOIO in place of GFP_KERNEL when allocating a new command with tcmu_alloc_cmd() and user ring space with tcmu_get_empty_block(). Link: https://lore.kernel.org/r/20191108082901.417950-1-damien.lemoal@wdc.com Reported-by:
Masato Suzuki <masato.suzuki@wdc.com> Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Acked-by:
Mike Christie <mchristi@redhat.com> Reviewed-by:
-
Damien Le Moal authored
struct scsi_cmnd cmd->req.resid_len which is returned and set respectively by the helper functions scsi_get_resid() and scsi_set_resid() is an unsigned int. Reflect this fact in the interface of these helper functions. Also fix compilation errors due to min() and max() type mismatch introduced by this change in scsi debug code, usb transport code and in the USB ENE card reader driver. Link: https://lore.kernel.org/r/20191030090847.25650-1-damien.lemoal@wdc.com Signed-off-by:
-
Bart Van Assche authored
Fix the following kernel warning: cpumask_of_node(-1): (unsigned)node >= nr_node_ids(1) Fixes: dcaa2136 ("scsi: lpfc: Change default IRQ model on AMD architectures") Link: https://lore.kernel.org/r/20191108225947.1395-1-jsmart2021@gmail.com Signed-off-by:
-
Bart Van Assche authored
Fix the following lockdep warning: ============================================ WARNING: possible recursive locking detected 5.4.0-rc6-dbg+ #2 Not tainted -------------------------------------------- systemd-udevd/130 is trying to acquire lock: ffffffff826b05d0 (cpu_hotplug_lock.rw_sem){++++}, at: irq_calc_affinity_vectors+0x63/0x90 but task is already holding lock: ffffffff826b05d0 (cpu_hotplug_lock.rw_sem){++++}, at: lpfc_sli4_enable_intr+0x422/0xd50 [lpfc] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(cpu_hotplug_lock.rw_sem); lock(cpu_hotplug_lock.rw_sem); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by systemd-udevd/130: #0: ffff8880d53fe210 (&dev->mutex){....}, at: __device_driver_lock+0x4a/0x70 #1: ffffffff826b05d0 (cpu_hotplug_lock.rw_sem){++++}, at: lpfc_sli4_enable_intr+0x422/0xd50 [lpfc] stack backtrace: CPU: 1 PID: 130 Comm: systemd-udevd Not tainted 5.4.0-rc6-dbg+ #2 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack+0xa5/0xe6 __lock_acquire.cold+0xf7/0x23a lock_acquire+0x106/0x240 cpus_read_lock+0x41/0xe0 irq_calc_affinity_vectors+0x63/0x90 __pci_enable_msix_range+0x10a/0x950 pci_alloc_irq_vectors_affinity+0x144/0x210 lpfc_sli4_enable_intr+0x4b2/0xd50 [lpfc] lpfc_pci_probe_one+0x1411/0x22b0 [lpfc] local_pci_probe+0x7c/0xc0 pci_device_probe+0x25d/0x390 really_probe+0x170/0x510 driver_probe_device+0x127/0x190 device_driver_attach+0x98/0xa0 __driver_attach+0xb6/0x1a0 bus_for_each_dev+0x100/0x150 driver_attach+0x31/0x40 bus_add_driver+0x246/0x300 driver_register+0xe0/0x170 __pci_register_driver+0xde/0xf0 lpfc_init+0x134/0x1000 [lpfc] do_one_initcall+0xda/0x47e do_init_module+0x10a/0x3b0 load_module+0x4318/0x47c0 __do_sys_finit_module+0x134/0x1d0 __x64_sys_finit_module+0x47/0x50 do_syscall_64+0x6f/0x2e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: dcaa2136 ("scsi: lpfc: Change default IRQ model on AMD architectures") Link: https://lore.kernel.org/r/20191107052158.25788-4-bvanassche@acm.org Signed-off-by: -
Bart Van Assche authored
Fix the following kernel bug report: BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/954 Fixes: d79c9e9d ("scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.") Link: https://lore.kernel.org/r/20191107052158.25788-2-bvanassche@acm.org Signed-off-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
Martin Wilck authored
Avoid an uninitialized value (0) for ha->fc4_type_priority being falsely interpreted as NVMe priority. Not strictly needed any more after the previous patch, but makes the fc4_type_priority handling more explicit. Link: https://lore.kernel.org/r/20191107224839.32417-3-martin.wilck@suse.com Tested-by:
David Bond <dbond@suse.com> Acked-by:
Himanshu Madhani <hmadhani@marvell.com> Reviewed-by:
Martin Wilck <mwilck@suse.com> Signed-off-by:
-
Martin Wilck authored
ha->fc4_type_priority is currently initialized only in qla81xx_nvram_config(). That makes it default to NVMe for other adapters. Fix it. Fixes: 84ed362a ("scsi: qla2xxx: Dual FCP-NVMe target port support") Link: https://lore.kernel.org/r/20191107224839.32417-2-martin.wilck@suse.com Tested-by:
-
Bart Van Assche authored
This patch fixes the following kernel warning: DMA-API: qla2xxx 0000:00:0a.0: device driver frees DMA memory with different size [device address=0x00000000c7b60000] [map size=4088 bytes] [unmap size=512 bytes] WARNING: CPU: 3 PID: 1122 at kernel/dma/debug.c:1021 check_unmap+0x4d0/0xbd0 CPU: 3 PID: 1122 Comm: rmmod Tainted: G O 5.4.0-rc1-dbg+ #1 RIP: 0010:check_unmap+0x4d0/0xbd0 Call Trace: debug_dma_free_coherent+0x123/0x173 dma_free_attrs+0x76/0xe0 qla2x00_mem_free+0x329/0xc40 [qla2xxx_scst] qla2x00_free_device+0x170/0x1c0 [qla2xxx_scst] qla2x00_remove_one+0x4f0/0x6d0 [qla2xxx_scst] pci_device_remove+0xd5/0x1f0 device_release_driver_internal+0x159/0x280 driver_detach+0x8b/0xf2 bus_remove_driver+0x9a/0x15a driver_unregister+0x51/0x70 pci_unregister_driver+0x2d/0x130 qla2x00_module_exit+0x1c/0xbc [qla2xxx_scst] __x64_sys_delete_module+0x22a/0x300 do_syscall_64+0x6f/0x2e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 3f006ac3 ("scsi: qla2xxx: Secure flash update support for ISP28XX") # v5.2-rc1~130^2~270. Cc: Michael Hernandez <mhernandez@marvell.com> Cc: Himanshu Madhani <hmadhani@marvell.com> Link: https://lore.kernel.org/r/20191106044226.5207-3-bvanassche@acm.org Reviewed-by:
-
Bart Van Assche authored
Since the code in qla_init.c is initiator code, remove the SCSI target core include directive. Cc: Himanshu Madhani <hmadhani@marvell.com> Link: https://lore.kernel.org/r/20191106044226.5207-2-bvanassche@acm.org Reviewed-by:
-
Himanshu Madhani authored
Link: https://lore.kernel.org/r/20191105150657.8092-9-hmadhani@marvell.com Reviewed-by:
-
Arun Easi authored
P2P needs to take the alternate plogi route. Link: https://lore.kernel.org/r/20191105150657.8092-8-hmadhani@marvell.com Reviewed-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
-
Arun Easi authored
On heavy loads, a memory leak of the srb_t structure is observed. This would make the qla2xxx_srbs cache gobble up memory. Fixes: 219d27d7 ("scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands") Cc: stable@vger.kernel.org # 5.2 Link: https://lore.kernel.org/r/20191105150657.8092-7-hmadhani@marvell.com Reviewed-by:
-
Quinn Tran authored
Current code assumes abort will remove the original command from the active list where scsi_done will not be called. Instead, the eh_abort thread will do the scsi_done. That is not the case. Instead, we have a double scsi_done calls triggering use after free. Abort will tell FW to release the command from FW possesion. The original command will return to ULP with error in its normal fashion via scsi_done. eh_abort path would wait for the original command completion before returning. eh_abort path will not perform the scsi_done call. Fixes: 219d27d7 ("scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands") Cc: stable@vger.kernel.org # 5.2 Link: https://lore.kernel.org/r/20191105150657.8092-6-hmadhani@marvell.com Reviewed-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
-
Quinn Tran authored
This patch fixes driver unload hang by removing msleep() Fixes: d7459527 ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191105150657.8092-5-hmadhani@marvell.com Reviewed-by:
-
Quinn Tran authored
when GPSC/GPDB switch command fails, driver just returns without doing a proper cleanup. This patch fixes this memory leak by calling sp->free() in the error path. Link: https://lore.kernel.org/r/20191105150657.8092-4-hmadhani@marvell.com Reviewed-by:
-
Quinn Tran authored
On switch, fabric and mgt command timeout, driver send Abort to tell FW to return the original command. If abort is timeout, then return both Abort and original command for cleanup. Fixes: 219d27d7 ("scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands") Cc: stable@vger.kernel.org # 5.2 Link: https://lore.kernel.org/r/20191105150657.8092-3-hmadhani@marvell.com Reviewed-by:
-
Quinn Tran authored
Current code will send PRLI with FC-NVMe bit set for the targets which support only FCP. This may result into issue with targets which do not understand NVMe and will go into a strange state. This patch would restart the login process by going back to PLOGI state. The PLOGI state will force the target to respond to correct PRLI request. Fixes: c76ae845 ("scsi: qla2xxx: Add error handling for PLOGI ELS passthrough") Cc: stable@vger.kernel.org # 5.4 Link: https://lore.kernel.org/r/20191105150657.8092-2-hmadhani@marvell.com Reviewed-by:
-
- Nov 06, 2019
-
-
Vinod Koul authored
Document "qcom,sm8150-ufshc" compatible string for UFS HC found on SM8150. Link: https://lore.kernel.org/r/20191024074802.26526-2-vkoul@kernel.org Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Acked-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Maurizio Lombardi authored
This patch renames some variables in chap_server_compute_hash() to make it harder to confuse the initiator's challenge with the target's challenge when the mutual chap authentication is used. Link: https://lore.kernel.org/r/20191017131037.9903-4-mlombard@redhat.com Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Signed-off-by:
-
Maurizio Lombardi authored
Link: https://lore.kernel.org/r/20191017131037.9903-3-mlombard@redhat.com Signed-off-by:
Chris Leech <cleech@redhat.com> Signed-off-by:
-
Maurizio Lombardi authored
This patch modifies the chap_server_compute_hash() function to make it agnostic to the choice of hash algorithm that is used. It also adds support to three new hash algorithms: SHA1, SHA256 and SHA3-256. The chap_got_response() function has been removed because the digest type validity is already checked by chap_server_open() Link: https://lore.kernel.org/r/20191028123822.5864-2-mlombard@redhat.com Signed-off-by:
-
Bart Van Assche authored
According to SBC-2 a TRANSFER LENGTH field of zero means that 256 logical blocks must be transferred. Make the SCSI tracing code follow SBC-2. Fixes: bf816235 ("[SCSI] add scsi trace core functions and put trace points") Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.com> Cc: Douglas Gilbert <dgilbert@interlog.com> Link: https://lore.kernel.org/r/20191105215553.185018-1-bvanassche@acm.org Signed-off-by:
-
James Smart authored
Update lpfc version to 12.6.0.1 Link: https://lore.kernel.org/r/20191105005708.7399-12-jsmart2021@gmail.com Signed-off-by:
-
James Smart authored
Some adapters support the ability to hold multiple adapter dumps on the adapter flash. Some adapters default to enabling this feature while others default to single-dump. Make support uniform by enabling dual dump by default. Link: https://lore.kernel.org/r/20191105005708.7399-11-jsmart2021@gmail.com Signed-off-by:
-
James Smart authored
The current driver attempts to allocate an interrupt vector per cpu using the systems managed IRQ allocator (flag PCI_IRQ_AFFINITY). The system IRQ allocator will either provide the per-cpu vector, or return fewer vectors. When fewer vectors, they are evenly spread between the numa nodes on the system. When run on an AMD architecture, if interrupts occur to a cpu that is not in the same numa node as the adapter generating the interrupt, there are extreme costs and overheads in performance. Thus, if 1:1 vector allocation is used, or the "balanced" vectors in the other numa nodes, performance can be hit significantly. A much more performant model is to allocate interrupts only on the cpus that are in the numa node where the adapter resides. I/O completion is still performed by the cpu where the I/O was generated. Unfortunately, there is no flag to request the managed IRQ subsystem allocate vectors only for the CPUs in the numa node as the adapter. On AMD architecture, revert the irq allocation to the normal style (non-managed) and then use irq_set_affinity_hint() to set the cpu affinity and disable user-space rebalancing. Tie the support into CPU offline/online. If the cpu being offlined owns a vector, the vector is re-affinitized to one of the other CPUs on the same numa node. If there are no more CPUs on the numa node, the vector has all affinity removed and lets the system determine where it's serviced. Similarly, when the cpu that owned a vector comes online, the vector is reaffinitized to the cpu. Link: https://lore.kernel.org/r/20191105005708.7399-10-jsmart2021@gmail.com Signed-off-by:
-
James Smart authored
The recent affinitization didn't address cpu offlining/onlining. If an interrupt vector is shared and the low order cpu owning the vector is offlined, as interrupts are managed, the vector is taken offline. This causes the other CPUs sharing the vector will hang as they can't get io completions. Correct by registering callbacks with the system for Offline/Online events. When a cpu is taken offline, its eq, which is tied to an interrupt vector is found. If the cpu is the "owner" of the vector and if the eq/vector is shared by other CPUs, the eq is placed into a polled mode. Additionally, code paths that perform io submission on the "sharing CPUs" will check the eq state and poll for completion after submission of new io to a wq that uses the eq. Similarly, when a cpu comes back online and owns an offlined vector, the eq is taken out of polled mode and rearmed to start driving interrupts for eq. Link: https://lore.kernel.org/r/20191105005708.7399-9-jsmart2021@gmail.com Signed-off-by:
-
James Smart authored
Current message on FAWWN events is rather cryptic. Expand the message to clarify its meaning. Link: https://lore.kernel.org/r/20191105005708.7399-8-jsmart2021@gmail.com Signed-off-by:
-
