- 01 Apr, 2020 3 commits
-
-
Sreekanth Reddy authored
Generic protection fault type kernel panic is observed when user performs soft (ordered) HBA unplug operation while IOs are running on drives connected to HBA. When user performs ordered HBA removal operation, the kernel calls PCI device's .remove() call back function where driver is flushing out all the outstanding SCSI IO commands with DID_NO_CONNECT host byte and also unmaps sg buffers allocated for these IO commands. However, in the ordered HBA removal case (unlike of real HBA hot removal), HBA device is still alive and hence HBA hardware is performing the DMA operations to those buffers on the system memory which are already unmapped while flushing out the outstanding SCSI IO commands and this leads to kernel panic. Don't flush out the outstanding IOs from .remove() path in case of ordered removal since HBA will be still alive in this case and it can complete the outstanding IOs. Flush out the outstanding IOs only in case of 'physical HBA hot unplug' where there won't be any communication with the HBA. During shutdown also it is possible that HBA hardware can perform DMA operations on those outstanding IO buffers which are completed with DID_NO_CONNECT by the driver from .shutdown(). So same above fix is applied in shutdown path as well. It is safe to drop the outstanding commands when HBA is inaccessible such as when permanent PCI failure happens, when HBA is in non-operational state, or when someone does a real HBA hot unplug operation. Since driver knows that HBA is inaccessible during these cases, it is safe to drop the outstanding commands instead of waiting for SCSI error recovery to kick in and clear these outstanding commands. Link: https://lore.kernel.org/r/1585302763-23007-1-git-send-email-sreekanth.reddy@broadcom.com Fixes: c666d3be ("scsi: mpt3sas: wait for and flush running commands on shutdown/unload") Cc: stable@vger.kernel.org #v4.14.174+ Signed-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Stanley Chu authored
Currently ufshcd driver assumes that bInitPowerMode parameter is not changed by any vendors thus device power mode can be set as "Active" during initialization. According to UFS JEDEC specification, device power mode shall be "Active" after HW Reset is triggered if the bInitPowerMode parameter in Device Descriptor is default value. By above description, we can set device power mode as "Active" after device reset is triggered by vendor's callback. With this change, the link startup performance can be improved in some cases by not setting link_startup_again as true in ufshcd_link_startup(). Link: https://lore.kernel.org/r/20200327095835.10293-1-stanley.chu@mediatek.comReviewed-by:
Can Guo <cang@codeaurora.org> Reviewed-by:
Asutosh Das <asutoshd@codeaurora.org> Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
-
Wu Bo authored
If the daemon is restarted or crashes while logging out of a session, the unbind session event sent by the kernel is not processed and is lost. When the daemon starts again, the session can't be unbound because the daemon is waiting for the event message. However, the kernel has already logged out and the event will not be resent. When iscsid restart is complete, logout session reports error: Logging out of session [sid: 6, target: iqn.xxxxx, portal: xx.xx.xx.xx,3260] iscsiadm: Could not logout of [sid: 6, target: iscsiadm -m node iqn.xxxxx, portal: xx.xx.xx.xx,3260]. iscsiadm: initiator reported error (9 - internal error) iscsiadm: Could not logout of all requested sessions Make sure the unbind event is emitted. [mkp: commit desc and applied by hand since patch was mangled] Link: https://lore.kernel.org/r/4eab1771-2cb3-8e79-b31c-923652340e99@huawei.comReviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Wu Bo <wubo40@huawei.com> Signed-off-by:
-
- 29 Mar, 2020 18 commits
-
-
Dick Kennedy authored
The default lun queue depth by the driver has been 30 for many years. However, this value, when used with more recent hardware, has actually throttled some tests that concentrate io on a lun. Increase the default lun queue depth to 64. Queue full handling, reported by the target, remains in effect and unchanged. Link: https://lore.kernel.org/r/20200323161935.40341-1-jsmart2021@gmail.comSigned-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
Javed Hasan authored
After all PRLI retries are exhausted, move rport state machine back to PLOGI state. Link: https://lore.kernel.org/r/20200327060208.17104-3-skashyap@marvell.comSigned-off-by:
Javed Hasan <jhasan@marvell.com> Signed-off-by:
Saurav Kashyap <skashyap@marvell.com> Signed-off-by:
-
Javed Hasan authored
If PRLI reject code indicates "rejected status", move rport state machine back to PLOGI state. Link: https://lore.kernel.org/r/20200327060208.17104-2-skashyap@marvell.comSigned-off-by:
-
Saurav Kashyap authored
Update version to 2.12.13. Link: https://lore.kernel.org/r/20200327054849.15947-4-skashyap@marvell.comSigned-off-by:
-
Saurav Kashyap authored
Driver received a SCSI completion after it posted the cleanup request. This leads to a problem that one ref count wasn't released leading to flush_active_ios to get struck. The callback from libfc never returned and other ports were not processed leading to APD. Decrease the refcnt as well as try to complete if something is waiting for completion. Link: https://lore.kernel.org/r/20200327054849.15947-3-skashyap@marvell.comSigned-off-by:
-
Javed Hasan authored
Filesystem goes to read-only after continuous error injection because RQE was handled in deferred context, leading to mismatch between CQE and RQE. Specifically, this patch makes the following changes: - Process the RQE with CQE in interrupt context, before putting it into the work queue. - Producer and consumer indices are also updated in the interrupt context to guarantee the the order of processing. [mkp: fixed bad indentation] Link: https://lore.kernel.org/r/20200327054849.15947-2-skashyap@marvell.comSigned-off-by:
-
David Disseldorp authored
Reads and writes in the XCOPY loop are synchronous, so needn't be heap allocated / freed with each loop. Link: https://lore.kernel.org/r/20200327141954.955-6-ddiss@suse.deReviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
David Disseldorp <ddiss@suse.de> Signed-off-by:
-
David Disseldorp authored
The I/O size is already bound by dev_attrib.hw_max_sectors, so increase the hardcoded XCOPY_MAX_SECTORS maximum to improve performance against backstores with high-latency. Link: https://lore.kernel.org/r/20200327141954.955-5-ddiss@suse.deReviewed-by:
-
David Disseldorp authored
The main target_xcopy_do_work() loop unnecessarily allocates an I/O buffer with each synchronous READ / WRITE pair. This commit significantly reduces allocations by reusing the XCOPY I/O buffer when possible. Link: https://lore.kernel.org/r/20200327141954.955-4-ddiss@suse.deReviewed-by:
-
David Disseldorp authored
The DISK BLOCK LENGTH field is carried with XCOPY target descriptors on the wire, but is currently unmarshalled during 0x02 segment descriptor passing. The unmarshalled value is currently unused, so drop it. Link: https://lore.kernel.org/r/20200327141954.955-3-ddiss@suse.deReviewed-by:
-
David Disseldorp authored
Link: https://lore.kernel.org/r/20200327141954.955-2-ddiss@suse.deReviewed-by:
-
Stanley Chu authored
Once fail happens during suspend and resume flow if the desired low power link state is H8, link recovery is required for MediaTek UFS controller. For resume flow, since power and clocks are already enabled before invoking vendor's resume callback, simply using ufshcd_link_recovery() inside callback is fine. For suspend flow, the device power enters low power mode or is disabled before suspend callback, thus ufshcd_link_recovery() can not be directly used in vendor callback. One solution is to set the link to off state and then ufshcd_host_reset_and_restore() will be executed by ufshcd_suspend(). Link: https://lore.kernel.org/r/20200327095329.10083-3-stanley.chu@mediatek.comReviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
-
Stanley Chu authored
Export ufshcd_link_recovery to allow vendors to recover failed link in vendor's callbacks. Link: https://lore.kernel.org/r/20200327095329.10083-2-stanley.chu@mediatek.comReviewed-by:
-
Subhash Jadavani authored
This change introduces a func ufshcd_set_clk_freq() to explicitly set clock frequency so that it can be used in reset_and_restore path and in ufshcd_scale_clks(). This change also cleans up the clock scaling error out path. [mkp: commit desc] Link: https://lore.kernel.org/r/1585214742-5466-2-git-send-email-cang@codeaurora.org Fixes: a3cd5ec5 ("scsi: ufs: add load based scaling of UFS gear") Reviewed-by:
Bean Huo <beanhuo@micron.com> Acked-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
-
James Smart authored
Update lpfc version to 12.8.0.0 Link: https://lore.kernel.org/r/20200322181304.37655-13-jsmart2021@gmail.comSigned-off-by:
-
James Smart authored
During code review, identified dss feature that was a prototype only and was never productized in SLI3. They shouldn't be there and prevents reuse of the command areas. Remove any code in the driver to deal with dss, including code to deal with fips, which is associated with the dss feature. Link: https://lore.kernel.org/r/20200322181304.37655-12-jsmart2021@gmail.comSigned-off-by:
-
James Smart authored
Currently driver ktime stats, measuring code paths, is NVME-specific. Convert the stats routines such that the code paths are generic, providing status for NVME and SCSI. Added ktime stat calls in SCSI queuecommand and cmpl routines. Link: https://lore.kernel.org/r/20200322181304.37655-11-jsmart2021@gmail.comSigned-off-by:
-
James Smart authored
The cpu io statistics were capped by a hard define limit of 128. This effectively was a max number of CPUs, not an actual CPU count, nor actual CPU numbers which can be even larger than both of those values. This made stats off/misleading and on large CPU count systems, wrong. Fix the stats so that all CPUs can have a stats struct. Fix the looping such that it loops by hdwq, finds CPUs that used the hdwq, and sum the stats, then display. Link: https://lore.kernel.org/r/20200322181304.37655-9-jsmart2021@gmail.comSigned-off-by:
-
- 27 Mar, 2020 19 commits
-
-
James Smart authored
Kernel is crashing with the following stacktrace: BUG: unable to handle kernel NULL pointer dereference at 00000000000005bc IP: lpfc_nvme_register_port+0x1a8/0x3a0 [lpfc] ... Call Trace: lpfc_nlp_state_cleanup+0x2b2/0x500 [lpfc] lpfc_nlp_set_state+0xd7/0x1a0 [lpfc] lpfc_cmpl_prli_prli_issue+0x1f7/0x450 [lpfc] lpfc_disc_state_machine+0x7a/0x1e0 [lpfc] lpfc_cmpl_els_prli+0x16f/0x1e0 [lpfc] lpfc_sli_sp_handle_rspiocb+0x5b2/0x690 [lpfc] lpfc_sli_handle_slow_ring_event_s4+0x182/0x230 [lpfc] lpfc_do_work+0x87f/0x1570 [lpfc] kthread+0x10d/0x130 ret_from_fork+0x35/0x40 During target side fault injections, it is possible to hit the NLP_WAIT_FOR_UNREG case in lpfc_nvme_remoteport_delete. A prior commit fixed a rebind and delete race condition, but called lpfc_nlp_put unconditionally. This triggered a deletion and the crash. Fix by movng nlp_put to inside the NLP_WAIT_FOR_UNREG case, where the nlp will be being unregistered/removed. Leave the reference if the flag isn't set. Link: https://lore.kernel.org/r/20200322181304.37655-8-jsmart2021@gmail.com Fixes: b15bd3e6 ("scsi: lpfc: Fix nvme remoteport registration race conditions") Signed-off-by: -
James Smart authored
The lpfc_sli4_wq_release() routine iterates for each interim value when updating the wq consuemr index. This wastes cycles and possibly confuses things as thevalue itterates (and the modulo logic is being applied). There's no reason for this. Just set it to the value from the hw. Link: https://lore.kernel.org/r/20200322181304.37655-7-jsmart2021@gmail.comSigned-off-by:
-
James Smart authored
Injecting EEH on a 32GB card is causing kernel oops The pci error handler is doing an IO flush and the offline code is also doing an IO flush. When the 1st flush is complete the hdwq is destroyed (freed), yet the second flush accesses the hdwq and crashes. Added a check in lpfc_sli4_fush_io_rings to check both the HBA_IOQ_FLUSH flag and the hdwq pointer to see if it is already set and not already freed. Link: https://lore.kernel.org/r/20200322181304.37655-6-jsmart2021@gmail.comSigned-off-by:
-
James Smart authored
SCSI layer sends driver IOs with more s/g segments than driver can handle. This results in "Too many sg segments from dma_map_sg. Config 64, seg_cnt 219" error messages from the lpfc_scsi_prep_dma_buf_s3() routine. The was due to use the driver using individual templates for pport and vport, host reset enabled or not, nvme vs scsi, etc. In the end, there was a combination for a vport that didn't match the pport. Rather than enumerating more templates and more discretionary assignments, revert to a base template that is copied to a template specific to the pport/vport. Then, based on role, attributes and sli type, modify the fields that are different for that port. Added a log message to lpfc_create_port to validate values. Link: https://lore.kernel.org/r/20200322181304.37655-5-jsmart2021@gmail.comSigned-off-by:
-
James Smart authored
In lpfc_nvmet_prep_fcp_wqe() the line "rsp->sg_cnt = 0" is modifying the transport's data structure. This may result in the transport believing the s/g list was already freed, thus may not unmap/free it properly. Lpfc driver should not modify the transport data structure. The zeroing of the sg_cnt is to avoid use of the transport's sgl in a subsequent loop where the driver builds the necessary requests for the adapter firmware to complete the IO. Change LLDD to use a local copy of the transport sg_cnt when building requests to be passed to the adapter fw. Link: https://lore.kernel.org/r/20200322181304.37655-4-jsmart2021@gmail.comSigned-off-by:
-
James Smart authored
The following lockdep error was reported when unloading the lpfc driver: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. ... Call Trace: dump_stack+0x96/0xe0 register_lock_class+0x8b8/0x8c0 ? lockdep_hardirqs_on+0x190/0x280 ? is_dynamic_key+0x150/0x150 ? wait_for_completion_interruptible+0x2a0/0x2a0 ? wake_up_q+0xd0/0xd0 __lock_acquire+0xda/0x21a0 ? register_lock_class+0x8c0/0x8c0 ? synchronize_rcu_expedited+0x500/0x500 ? __call_rcu+0x850/0x850 lock_acquire+0xf3/0x1f0 ? del_timer_sync+0x5/0xb0 del_timer_sync+0x3c/0xb0 ? del_timer_sync+0x5/0xb0 lpfc_pci_remove_one.cold.102+0x8b7/0x935 [lpfc] ... Unloading the driver resulted in a call to del_timer_sync for the cpuhp_poll_timer. However the call to setup the timer had never been made, so the timer structures used by lockdep checking were not initialized. Unconditionally call setup_timer for the cpuhp_poll_timer during driver initialization. Calls to start the timer remain "as needed". Link: https://lore.kernel.org/r/20200322181304.37655-3-jsmart2021@gmail.comSigned-off-by:
-
James Smart authored
The following kasan bug was called out: BUG: KASAN: slab-out-of-bounds in lpfc_unreg_login+0x7c/0xc0 [lpfc] Read of size 2 at addr ffff889fc7c50a22 by task lpfc_worker_3/6676 ... Call Trace: dump_stack+0x96/0xe0 ? lpfc_unreg_login+0x7c/0xc0 [lpfc] print_address_description.constprop.6+0x1b/0x220 ? lpfc_unreg_login+0x7c/0xc0 [lpfc] ? lpfc_unreg_login+0x7c/0xc0 [lpfc] __kasan_report.cold.9+0x37/0x7c ? lpfc_unreg_login+0x7c/0xc0 [lpfc] kasan_report+0xe/0x20 lpfc_unreg_login+0x7c/0xc0 [lpfc] lpfc_sli_def_mbox_cmpl+0x334/0x430 [lpfc] ... When processing the completion of a "Reg Rpi" login mailbox command in lpfc_sli_def_mbox_cmpl, a call may be made to lpfc_unreg_login. The vpi is extracted from the completing mailbox context and passed as an input for the next. However, the vpi stored in the mailbox command context is an absolute vpi, which for SLI4 represents both base + offset. When used with a non-zero base component, (function id > 0) this results in an out-of-range access beyond the allocated phba->vpi_ids array. Fix by subtracting the function's base value to get an accurate vpi number. Link: https://lore.kernel.org/r/20200322181304.37655-2-jsmart2021@gmail.comSigned-off-by:
-
Alex Dewar authored
The file aic79xx_core.c still contains some FreeBSD-specific code/macro guards, although cross-compatibility was in theory removed with commit cca6cb8a ("scsi: aic7xxx: Fix build using bare-metal toolchain"). Remove it. Link: https://lore.kernel.org/r/20200326193817.12568-1-alex.dewar@gmx.co.ukSigned-off-by:
Alex Dewar <alex.dewar@gmx.co.uk> Signed-off-by:
-
Can Guo authored
We were setting bActiveICCLevel attribute for UFS device only once but the type of this attribute has changed from persistent to volatile since UFS device specification v2.1. This attribute is set to the default value after power cycle or hardware reset event. It isn't safe to rely on prefetched data (only used for bActiveICCLevel attribute now). Hence this change removes the code related to data prefetching and set this parameter on every attempt to probe the UFS device. Tested-by:
-
Christoph Hellwig authored
dc395x_bios_param was only different from the default when the CONFIG_SCSI_DC395x_TRMS1040_TRADMAP symbol is true, but that symbol doesn't exist in the Kconfig system and thus can't be set. Link: https://lore.kernel.org/r/20200325105505.1028582-1-hch@lst.deSigned-off-by:
-
Wu Bo authored
Fix an error count for active session if the total_cmds is invalid on the function iscsi_session_setup(). Decrement the number of active sessions before the funcion return. Link: https://lore.kernel.org/r/EDBAAA0BBBA2AC4E9C8B6B81DEEE1D6916A28542@DGGEML525-MBS.china.huawei.comReviewed-by:
Lee Duncan <lduncan@suuse.com> Signed-off-by:
-
Don Brace authored
Correct race condition where ioaccel is re-enabled before the raid_map is updated. For RAID_1, RAID_1ADM, and RAID 5/6 there is a BUG_ON called which is bad. - Change event thread to disable ioaccel only. Send all requests down the RAID path instead. - Have rescan thread handle offload_enable. - Since there is only one rescan allowed at a time, turning offload_enabled on/off should not be racy. Each handler queues up a rescan if one is already in progress. - For timing diagram, offload_enabled is initially off due to a change (transformation: splitmirror/remirror), ... otbe = offload_to_be_enabled oe = offload_enabled Time Event Rescan Completion Request Worker Worker Thread Thread ---- ------ ------ ---------- ------- T0 | | + UA | T1 | + rescan started | 0x3f | T2 + Event | | 0x0e | T3 + Ack msg | | | T4 | + if (!dev[i]->oe && | | T5 | | dev[i]->otbe) | | T6 | | get_raid_map | | T7 + otbe = 1 | | | T8 | | | | T9 | + oe = otbe | | T10 | | | + ioaccel request T11 * BUG_ON T0 - I/O completion with UA 0x3f 0x0e sets rescan flag. T1 - rescan worker thread starts a rescan. T2 - event comes in T3 - event thread starts and issues "Acknowledge" message ... T6 - rescan thread has bypassed code to reload new raid map. ... T7 - event thread runs and sets offload_to_be_enabled ... T9 - rescan thread turns on offload_enabled. T10- request comes in and goes down ioaccel path. T11- BUG_ON. - After the patch is applied, ioaccel_enabled can only be re-enabled in the re-scan thread. Link: https://lore.kernel.org/r/158472877894.14200.7077843399036368335.stgit@brunhildaReviewed-by:Scott Teel <scott.teel@microsemi.com> Reviewed-by:
Matt Perricone <matt.perricone@microsemi.com> Reviewed-by:
Scott Benesh <scott.benesh@microsemi.com> Signed-off-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Link: https://lore.kernel.org/r/20200319222533.GA20577@embeddedor.comSigned-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Manish Rangankar authored
Add PCI shutdown handler support for supporting wake-on-lan feature. Link: https://lore.kernel.org/r/20200319083811.19499-3-mrangankar@marvell.comSigned-off-by:
Manish Rangankar <mrangankar@marvell.com> Signed-off-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
-
Manish Rangankar authored
This patch adds the mfw error recovery process in the qedi driver. The process includes a partial/customized driver unload and load to reset context by preserving active iSCSI session kernel state. Link: https://lore.kernel.org/r/20200319083811.19499-2-mrangankar@marvell.comSigned-off-by:
-
Can Guo authored
Block layer RPM is enabled for the genernal UFS SCSI devices when they are probed by their driver. However block layer RPM is not enabled for UFS well-known SCSI devices. As UFS SCSI devices have their corresponding BSG char devices, accessing a BSG char device via IOCTL may send requests to its corresponding SCSI device through its request queue. If BSG IOCTL sends a request to a well-known SCSI device when HBA is not runtime active, due to block layer RPM not being enabled for the well-known SCSI devices, the HBA, which is at the top of a SCSI device's parent chain, will not be resumed. This change enables block layer RPM for the well-known SCSI devices so that block layer can handle RPM for the well-known SCSI devices just like for the general SCSI devices. Reviewed-by:
-
Asutosh Das authored
Override devfreq parameters for power-performance trade-off. Link: https://lore.kernel.org/r/b6875729b6072134985c9113a820cf60a2af22e7.1585160616.git.asutoshd@codeaurora.orgAcked-by:
-
Asutosh Das authored
Vendor drivers may have a need to update the polling interval and thresholds. Provide a vops for vendor drivers to use. Link: https://lore.kernel.org/r/acd79e00396cff855256adad47f615ccdbde85ac.1585160616.git.asutoshd@codeaurora.orgAcked-by:
-
Asutosh Das authored
Currently, the frequency that devfreq provides the driver always leads the clocks to be scaled up. Hence, round the clock-rate to the nearest frequency before deciding to scale. Also update the devfreq statistics of current frequency. Link: https://lore.kernel.org/r/d0c6c22455811e9f0eda01f9bc70d1398b51b2bd.1585160616.git.asutoshd@codeaurora.orgAcked-by:
-
