- 15 Mar, 2022 2 commits
-
-
John Garry authored
The internal abort feature is common to hisi_sas and pm8001 HBAs, and the driver support is similar also, so add a common handler. Two modes of operation will be supported: - single: Abort a single tagged command - device: Abort all commands associated with a specific domain device A new protocol is added, SAS_PROTOCOL_INTERNAL_ABORT, so the common queue command API may be re-used. Only add "single" support as a first step. Link: https://lore.kernel.org/r/1647001432-239276-2-git-send-email-john.garry@huawei.comTested-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com> Acked-by:
Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
James Smart authored
The soft_wwpn/soft_wwn functionality, which allows the driver to modify service parameters in an attempt to override the adapter-assigned WWN, was originally attempted to be removed roughly 6 yrs ago as new fabric features were being introduced that clashed with the implementation. In the end, the feature was left in with the user being responsible if things went south. We've reached a point where soft_wwn is no longer functional and is failing in almost all production use cases. Use of Fabric features such as Fabric Assigned WWPN and Automatic DPORT is now prevalent and the features require coordination between the adapter and driver that can't be solved by the simplistic update of the service parameters. As it is no longer functional, the feature is to be removed. There are still ways to override the adapter-assigned WWN but they require the admin to invoke bios/efi level menus. Link: https://lore.kernel.org/r/20220310154845.11125-1-jsmart2021@gmail.comReviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Co-developed-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
- 09 Mar, 2022 7 commits
-
-
Peter Wang authored
When ufs initializes without scmd->device->sector_size set, scsi_get_lba() will get a wrong shift number and trigger an ubsan error. The shift exponent 4294967286 is too large for the 64-bit type 'sector_t' (aka 'unsigned long long'). Call scsi_get_lba() only when opcode is READ_10/WRITE_10/UNMAP. Link: https://lore.kernel.org/r/20220307111752.10465-1-peter.wang@mediatek.comReviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Peter Wang <peter.wang@mediatek.com> Signed-off-by:
-
Randy Dunlap authored
Make a variety of corrections to ufs.rst: - add spaces around parenthetical phrases - correct singular/plural grammar and nouns - correct punctuation - add article adjectives - add hyphens to multi-word adjectives - spell Lun as LUN - spell upiu as UPIU (in text, not code examples) - don't capitalize generic "specification" Link: https://lore.kernel.org/r/20220307013224.5130-1-rdunlap@infradead.org Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: Avri Altman <avri.altman@wdc.com> 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:
-
Sreekanth Reddy authored
The driver must perform its 4GB boundary check using the pool's DMA address instead of using the virtual address. Link: https://lore.kernel.org/r/20220303140230.13098-1-sreekanth.reddy@broadcom.com Fixes: d6adc251 ("scsi: mpt3sas: Force PCIe scatterlist allocations to be within same 4 GB region") Signed-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
When scsi_dma_map() fails by returning a sges_left value less than zero, the amount of logging produced can be extremely high. In a recent end-user environment, 1200 messages per second were being sent to the log buffer. This eventually overwhelmed the system and it stalled. These error messages are not needed. Remove them. Link: https://lore.kernel.org/r/20220303140203.12642-1-sreekanth.reddy@broadcom.comSuggested-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Jianglei Nie authored
fc_exch_release(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free. Return after the fc_exch_release() call to avoid use after free. Link: https://lore.kernel.org/r/20220303015115.459778-1-niejianglei2021@163.comReviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Jianglei Nie <niejianglei2021@163.com> Signed-off-by:
-
Damien Le Moal authored
The use of the 'locked' boolean variable to control locking and unlocking of the qc_lock spinlock of struct sdebug_queue confuses sparse, leading to a warning about an unexpected unlock. Simplify the qc_lock lock/unlock handling code of this function to avoid this warning by removing the 'locked' boolean variable. This change also fixes unlocked access to the in_use_bm bitmap with the find_first_bit() function. Link: https://lore.kernel.org/r/20220301113009.595857-3-damien.lemoal@opensource.wdc.com Fixes: b05d4e48 ("scsi: scsi_debug: Refine sdebug_blk_mq_poll()") Cc: stable@vger.kernel.org Signed-off-by:
-
Damien Le Moal authored
The return statement inside the sdeb_read_lock(), sdeb_read_unlock(), sdeb_write_lock() and sdeb_write_unlock() confuse sparse, leading to many warnings about unexpected unlocks in the resp_xxx() functions. Modify the lock/unlock functions using the __acquire() and __release() inline annotations for the sdebug_no_rwlock == true case to avoid these warnings. Link: https://lore.kernel.org/r/20220301113009.595857-2-damien.lemoal@opensource.wdc.comAcked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
- 02 Mar, 2022 24 commits
-
-
Adrian Hunter authored
Kernel messages produced during runtime PM can cause a never-ending cycle because user space utilities (e.g. journald or rsyslog) write the messages back to storage, causing runtime resume, more messages, and so on. Messages that tell of things that are expected to happen, are arguably unnecessary, so suppress them. UFS driver messages are changes to from dev_err() to dev_dbg() which means they will not display unless activated by dynamic debug of building with -DDEBUG. sdev->silence_suspend is set to skip messages from sd_suspend_common() "Synchronizing SCSI cache", "Stopping disk" and scsi_report_sense() "Power-on or device reset occurred" message (Note, that message appears when the LUN is accessed after runtime PM, not during runtime PM) Example messages from Ubuntu 21.10: $ dmesg | tail [ 1620.380071] ufshcd 0000:00:12.5: ufshcd_print_pwr_info:[RX, TX]: gear=[1, 1], lane[1, 1], pwr[SLOWAUTO_MODE, SLOWAUTO_MODE], rate = 0 [ 1620.408825] ufshcd 0000:00:12.5: ufshcd_print_pwr_info:[RX, TX]: gear=[4, 4], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2 [ 1620.409020] ufshcd 0000:00:12.5: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0 [ 1620.409524] sd 0:0:0:0: Power-on or device reset occurred [ 1622.938794] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 1622.939184] ufs_device_wlun 0:0:0:49488: Power-on or device reset occurred [ 1625.183175] ufshcd 0000:00:12.5: ufshcd_print_pwr_info:[RX, TX]: gear=[1, 1], lane[1, 1], pwr[SLOWAUTO_MODE, SLOWAUTO_MODE], rate = 0 [ 1625.208041] ufshcd 0000:00:12.5: ufshcd_print_pwr_info:[RX, TX]: gear=[4, 4], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2 [ 1625.208311] ufshcd 0000:00:12.5: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0 [ 1625.209035] sd 0:0:0:0: Power-on or device reset occurred Note for stable: depends on patch "scsi: core: sd: Add silence_suspend flag to suppress some PM messages". Link: https://lore.kernel.org/r/20220228113652.970857-3-adrian.hunter@intel.com Cc: stable@vger.kernel.org Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Adrian Hunter authored
Kernel messages produced during runtime PM can cause a never-ending cycle because user space utilities (e.g. journald or rsyslog) write the messages back to storage, causing runtime resume, more messages, and so on. Messages that tell of things that are expected to happen are arguably unnecessary, so add a flag to suppress them. This flag is used by the UFS driver. Link: https://lore.kernel.org/r/20220228113652.970857-2-adrian.hunter@intel.com Cc: stable@vger.kernel.org Signed-off-by:
-
Hannes Reinecke authored
We only need the rport structure for lpfc_chk_tgt_mapped(). Link: https://lore.kernel.org/r/20220301143718.40913-6-hare@suse.de Cc: James Smart <james.smart@broadcom.com> Reviewed-by:
-
Hannes Reinecke authored
Instead of passing in a scsi_cmnd we should be using the rport; we already have the target and LUN ID as parameters, so there's no need to pass the scsi_cmnd too. Link: https://lore.kernel.org/r/20220301143718.40913-5-hare@suse.de Cc: James Smart <james.smart@broadcom.com> Reviewed-by:
-
Hannes Reinecke authored
Use fc_block_rport() instead of fc_block_scsi_eh() as the SCSI command will be removed as argument for SCSI EH functions. Link: https://lore.kernel.org/r/20220301143718.40913-4-hare@suse.de Cc: James Smart <james.smart@broadcom.com> Reviewed-by:
-
Hannes Reinecke authored
The default SCSI EH action for a non-existing EH callback is to return FAILED, so having a callback just returning FAILED is pointless. Link: https://lore.kernel.org/r/20220301143718.40913-3-hare@suse.de Cc: James Smart <james.smart@broadcom.com> Reviewed-by:
-
Hannes Reinecke authored
lpfc_bus_reset_handler() is really just a loop calling lpfc_target_reset_handler() over all targets, which is what the error handler will be doing anyway. Link: https://lore.kernel.org/r/20220301143718.40913-2-hare@suse.de Cc: James Smart <james.smart@broadcom.com> Reviewed-by:
-
Zheyu Ma authored
During the process of driver probing, the probe function should return < 0 for failure, otherwise the kernel will treat value >= 0 as success. Set 'err' to the error value returned by dma_set_mask() in case of failure. Link: https://lore.kernel.org/r/1646060055-11361-1-git-send-email-zheyuma97@gmail.comReviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
-
Mike Christie authored
When the workqueue code was created it didn't allow variable args so we have been using a temp buffer. Drop that. Link: https://lore.kernel.org/r/20220226230435.38733-7-michael.christie@oracle.comReviewed-by:
Chris Leech <cleech@redhat.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
-
Mike Christie authored
Use the session workqueue for recovery and unbinding. If there are delays during device blocking/cleanup then it will no longer affect other sessions. Link: https://lore.kernel.org/r/20220226230435.38733-6-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
We currently allocate a workqueue per host and only use it for removing the target. For the session per host case we could be using this workqueue to be able to do recoveries (block, unblock, timeout handling) in parallel. To also allow offload drivers to do their session recoveries in parallel, this drops the per host workqueue and replaces it with a per session one. Link: https://lore.kernel.org/r/20220226230435.38733-5-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
qla4xxx does not use iscsi_scan_finished() anymore so remove it. Link: https://lore.kernel.org/r/20220226230435.38733-4-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
When the iSCSI class was added upstream, blocking a queue was fast because it just set some flag bits and didn't handle I/O that was in the process of being sent to the driver. That's no longer the case so blocking a queue is expensive and we can end up with a backlog of blocks by the time we have relogged in and are trying to start the queues. For the session unblock case, this has try to cancel the block and recovery work in case they are still queued so we can avoid unneeded queue manipulations. For removal, we also now try to cancel all the recovery related works since a couple lines down we will set the session and device state so running those functions are not necessary. Link: https://lore.kernel.org/r/20220226230435.38733-3-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If the user sets the iscsi_eh_timer_workq/iscsi_eh workqueue's max_active to greater than 1, the recovery_work could be running when __iscsi_unblock_session() runs. The cancel_delayed_work() will then not wait for the running work and we can race where we end up with the wrong session state and scsi_device state set. This replaces the cancel_delayed_work() with the sync version. Link: https://lore.kernel.org/r/20220226230435.38733-2-michael.christie@oracle.comReviewed-by:
-
James Smart authored
In the original FPIN commit, stats were incremented by the event_count. Event_count is the minimum # of events that must occur before an FPIN is sent. Thus, its not the actual number of events, and could be significantly off (too low) as it doesn't reflect anything not reported. Rather than attempt to count events, have the statistic count how many FPINS cross the threshold and were reported. Link: https://lore.kernel.org/r/20220301175536.60250-1-jsmart2021@gmail.com Fixes: 3dcfe0de ("scsi: fc: Parse FPIN packets and update statistics") Cc: <stable@vger.kernel.org> # v5.11+ Cc: Shyam Sundar <ssundar@marvell.com> Cc: Nilesh Javali <njavali@marvell.com> Reviewed-by:
-
Damien Le Moal authored
Sparse throws a warning about context imbalance ("different lock contexts for basic block") in sas_form_port() as it gets confused with the fact that a port is locked within one of the two search loops and unlocked afterward outside of the search loops once the phy is added to the port. Since this code is not easy to follow, improve it by factoring out the code adding the phy to the port once the port is locked into the helper function sas_form_port_add_phy(). This helper can then be called directly within the port search loops, avoiding confusion and clearing the sparse warning. Link: https://lore.kernel.org/r/20220228094857.557329-1-damien.lemoal@opensource.wdc.comReviewed-by: -
Christoph Hellwig authored
This header is empty now except for an include of <linux/blk-mq.h>, so remove it. Link: https://lore.kernel.org/r/20220224175552.988286-9-hch@lst.deReviewed-by:
-
Christoph Hellwig authored
Let submitters initialize the scmd->allowed field directly instead of indirecting through struct scsi_request and remove the now superfluous structure. Link: https://lore.kernel.org/r/20220224175552.988286-8-hch@lst.deReviewed-by:
-
Christoph Hellwig authored
Prepare for removing the scsi_request structure by moving the result field to struct scsi_cmnd. Link: https://lore.kernel.org/r/20220224175552.988286-7-hch@lst.deReviewed-by:
-
Christoph Hellwig authored
Prepare for removing the scsi_request structure by moving the resid_len field to struct scsi_cmnd. Link: https://lore.kernel.org/r/20220224175552.988286-6-hch@lst.deReviewed-by:
-
Christoph Hellwig authored
Just use the sense_buffer field in struct scsi_cmnd for the sense data and move the sense_len field over to struct scsi_cmnd. Link: https://lore.kernel.org/r/20220224175552.988286-5-hch@lst.deReviewed-by:
-
Christoph Hellwig authored
Now that each scsi_request is backed by a scsi_cmnd, there is no need to indirect the CDB storage. Change all submitters of SCSI passthrough requests to store the CDB information directly in the scsi_cmnd, and while doing so allocate the full 32 bytes that cover all Linux supported SCSI hosts instead of requiring dynamic allocation for > 16 byte CDBs. On 64-bit systems this does not change the size of the scsi_cmnd at all, while on 32-bit systems it slightly increases it for now, but that increase will be made up by the removal of the remaining scsi_request fields. Link: https://lore.kernel.org/r/20220224175552.988286-4-hch@lst.deReviewed-by:
-
Christoph Hellwig authored
Replace the big fat memset that requires saving and restoring various fields with just initializing those fields that need initialization. All the clearing to 0 is moved to scsi_prepare_cmd() as scsi_ioctl_reset() alreadly uses kzalloc() to allocate a pre-zeroed command. This is still conservative and can probably be optimized further. Link: https://lore.kernel.org/r/20220224175552.988286-3-hch@lst.deReviewed-by:
-
Christoph Hellwig authored
Copy directly from the se_cmd CDB to the one in the scsi_request. This temporarily limits the pscsi backend to supporting only up to 16 byte CDBs, but this restriction will be lifted later in this series. Link: https://lore.kernel.org/r/20220224175552.988286-2-hch@lst.deSigned-off-by:
-
- 28 Feb, 2022 7 commits
-
-
John Garry authored
Function queue_work() returns a bool, so use a bool to hold this value for the return code from callers, which should make the code a tiny bit more clear. Also take this opportunity to condense the code of the those callers, such as sas_queue_work(), as suggested by Damien. Link: https://lore.kernel.org/r/1645786656-221630-3-git-send-email-john.garry@huawei.comReviewed-by:
-
John Garry authored
Nobody checks the return codes, so make them return void. Indeed, if the LLDD cannot send an event, nothing much can be done in the LLDD about it. Also remove prototype for sas_notify_phy_event() in sas_internal.h, which should not be there. Link: https://lore.kernel.org/r/1645786656-221630-2-git-send-email-john.garry@huawei.comReviewed-by:
Xiang Chen <chenxiang66@hisilicon.com> Reviewed-by:
-
Xingui Yang authored
In case of SSP underflow allow the response frame IU to be examined for setting the response stat value rather than always setting SAS_DATA_UNDERRUN. This will mean that we call sas_ssp_task_response() in those scenarios and may send sense data to upper layer. Such a condition would be for bad blocks were we just reporting an underflow error to upper layer, but now the sense data will tell immediately that the media is faulty. Link: https://lore.kernel.org/r/1645703489-87194-7-git-send-email-john.garry@huawei.comSigned-off-by:
Xingui Yang <yangxingui@huawei.com> Signed-off-by:
Qi Liu <liuqi115@huawei.com> Signed-off-by:
-
Xiang Chen authored
Add a file operation for "cnt" file under bist directory, so users can only read "cnt" or clear "cnt" to zero, but cannot randomly modify. Link: https://lore.kernel.org/r/1645703489-87194-6-git-send-email-john.garry@huawei.comSigned-off-by:
-
Qi Liu authored
To avoid doubt, rename the error labels to indicate the action they will take. Link: https://lore.kernel.org/r/1645703489-87194-5-git-send-email-john.garry@huawei.comSigned-off-by:
-
Qi Liu authored
If the driver probe fails to request the channel IRQ or fatal IRQ, the driver will free the IRQ vectors before freeing the IRQs in free_irq(), and this will cause a kernel BUG like this: ------------[ cut here ]------------ kernel BUG at drivers/pci/msi.c:369! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: free_msi_irqs+0x118/0x13c pci_disable_msi+0xfc/0x120 pci_free_irq_vectors+0x24/0x3c hisi_sas_v3_probe+0x360/0x9d0 [hisi_sas_v3_hw] local_pci_probe+0x44/0xb0 work_for_cpu_fn+0x20/0x34 process_one_work+0x1d0/0x340 worker_thread+0x2e0/0x460 kthread+0x180/0x190 ret_from_fork+0x10/0x20 ---[ end trace b88990335b610c11 ]--- So we use devm_add_action() to control the order in which we free the vectors. Link: https://lore.kernel.org/r/1645703489-87194-4-git-send-email-john.garry@huawei.comSigned-off-by:
-
Xiang Chen authored
The time of phyup not only depends on the controller but also the type of disk connected. As an example, from experience, for some SATA disks the amount of time from reset/power-on to receive the D2H FIS for phyup can take upto and more than 10s sometimes. According to the specification of some SATA disks such as ST14000NM0018, the max time from power-on to ready is 30s. Based on this the current timeout of phyup at 2s which is not enough. So set the value as HISI_SAS_WAIT_PHYUP_TIMEOUT (30s) in hisi_sas_control_phy(). For v3 hw there is a pre-existing workaround for a HW bug, being that we issue a link reset when the OOB occurs but the phyup does not. The current phyup timeout is HISI_SAS_WAIT_PHYUP_TIMEOUT. So if this does occur from when issuing a phy enable or similar via hisi_sas_control_phy(), the subsequent HW workaround linkreset processing calls hisi_sas_control_phy(), but this will pend the original phy reset timing out, so it is safe. Link: https://lore.kernel.org/r/1645703489-87194-3-git-send-email-john.garry@huawei.comSigned-off-by:
-
