- 01 Aug, 2022 11 commits
-
-
Steffen Maier authored
Case (1): The only waiter on wka_port->completion_wq is zfcp_fc_wka_port_get() trying to open a WKA port. As such it should only be woken up by WKA port *open* responses, not by WKA port close responses. Case (2): A close WKA port response coming in just after having sent a new open WKA port request and before blocking for the open response with wait_event() in zfcp_fc_wka_port_get() erroneously renders the wait_event a NOP because the close handler overwrites wka_port->status. Hence the wait_event condition is erroneously true and it does not enter blocking state. With non-negligible probability, the following time space sequence happens depending on timing without this fix: user process ERP thread zfcp work queue tasklet system work queue ============ ========== =============== ======= ================= $ echo 1 > online zfcp_ccw_set_online zfcp_ccw_activate zfcp_erp_adapter_reopen msleep scan backoff zfcp_erp_strategy | ... | zfcp_erp_action_cleanup | ... | queue delayed scan_work | queue ns_up_work | ns_up_work: | zfcp_fc_wka_port_get | open wka request | open response | GSPN FC-GS | RSPN FC-GS [NPIV-only] | zfcp_fc_wka_port_put | (--wka->refcount==0) | sched delayed wka->work | ~~~Case (1)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ zfcp_erp_wait flush scan_work | wka->work: | wka->status=CLOSING | close wka request | scan_work: | zfcp_fc_wka_port_get | (wka->status==CLOSING) | wka->status=OPENING | open wka request | wait_event | | close response | | wka->status=OFFLINE | | wake_up /*WRONG*/ ~~~Case (2)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | wka->work: | wka->status=CLOSING | close wka request zfcp_erp_wait flush scan_work | scan_work: | zfcp_fc_wka_port_get | (wka->status==CLOSING) | wka->status=OPENING | open wka request | close response | wka->status=OFFLINE | wake_up /*WRONG&NOP*/ | wait_event /*NOP*/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | (wka->status!=ONLINE) | return -EIO | return early open response wka->status=ONLINE wake_up /*NOP*/ So we erroneously end up with no automatic port scan. This is a big problem when it happens during boot. The timing is influenced by v3.19 commit 18f87a67 ("zfcp: auto port scan resiliency"). Fix it by fully mutually excluding zfcp_fc_wka_port_get() and zfcp_fc_wka_port_offline(). For that to work, we make the latter block until we got the response for a close WKA port. In order not to penalize the system workqueue, we move wka_port->work to our own adapter workqueue. Note that before v2.6.30 commit 828bc121 ("[SCSI] zfcp: Set WKA-port to offline on adapter deactivation"), zfcp did block in zfcp_fc_wka_port_offline() as well, but with a different condition. While at it, make non-functional cleanups to improve code reading in zfcp_fc_wka_port_get(). If we cannot send the WKA port open request, don't rely on the subsequent wait_event condition to immediately let this case pass without blocking. Also don't want to rely on the additional condition handling the refcount to be skipped just to finally return with -EIO. Link: https://lore.kernel.org/r/20220729162529.1620730-1-maier@linux.ibm.com Fixes: 5ab944f9 ("[SCSI] zfcp: attach and release SAN nameserver port on demand") Cc: <stable@vger.kernel.org> #v2.6.28+ Reviewed-by:Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Steffen Maier <maier@linux.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Bart Van Assche authored
There are two .exit_cmd_priv implementations. Both implementations use resources associated with the SCSI host. Make sure that these resources are still available when .exit_cmd_priv is called by moving the .exit_cmd_priv calls from scsi_host_dev_release() to scsi_forget_host(). Moving blk_mq_free_tag_set() from scsi_host_dev_release() to scsi_remove_host() is safe because scsi_forget_host() waits until all SCSI devices associated with the host have been removed. Fix the following use-after-free: ================================================================== BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp] Read of size 8 at addr ffff888100337000 by task multipathd/16727 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db kasan_report+0xab/0x120 srp_exit_cmd_priv+0x27/0xd0 [ib_srp] scsi_mq_exit_request+0x4d/0x70 blk_mq_free_rqs+0x143/0x410 __blk_mq_free_map_and_rqs+0x6e/0x100 blk_mq_free_tag_set+0x2b/0x160 scsi_host_dev_release+0xf3/0x1a0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_device_dev_release_usercontext+0x4c1/0x4e0 execute_in_process_context+0x23/0x90 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_disk_release+0x3f/0x50 device_release+0x54/0xe0 kobject_put+0xa5/0x120 disk_release+0x17f/0x1b0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 dm_put_table_device+0xa3/0x160 [dm_mod] dm_put_device+0xd0/0x140 [dm_mod] free_priority_group+0xd8/0x110 [dm_multipath] free_multipath+0x94/0xe0 [dm_multipath] dm_table_destroy+0xa2/0x1e0 [dm_mod] __dm_destroy+0x196/0x350 [dm_mod] dev_remove+0x10c/0x160 [dm_mod] ctl_ioctl+0x2c2/0x590 [dm_mod] dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Link: https://lore.kernel.org/r/20220728221851.1822295-5-bvanassche@acm.org Fixes: 65ca846a ("scsi: core: Introduce {init,exit}_cmd_priv()") Cc: Christoph Hellwig <hch@lst.de> Cc: Mike Christie <michael.christie@oracle.com> Cc: Hannes Reinecke <hare@suse.de> Cc: John Garry <john.garry@huawei.com> Cc: Li Zhijian <lizhijian@fujitsu.com> Reported-by:
Li Zhijian <lizhijian@fujitsu.com> Tested-by:
Ming Lei <ming.lei@redhat.com> Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Ming Lei authored
Swap two statements in scsi_device_put() now that it is guaranteed that SCSI hosts outlive SCSI devices. Remove the reference counting code from scsi_sysfs.c that became superfluous because SCSI hosts now outlive SCSI devices. Link: https://lore.kernel.org/r/20220728221851.1822295-4-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Ming Lei <ming.lei@redhat.com> Cc: Mike Christie <michael.christie@oracle.com> Cc: Hannes Reinecke <hare@suse.de> Cc: John Garry <john.garry@huawei.com> Reviewed-by:
-
Ming Lei authored
Fix the race conditions between SCSI LLD kernel module unloading and SCSI device and target removal by making sure that SCSI hosts are destroyed after all associated target and device objects have been freed. Link: https://lore.kernel.org/r/20220728221851.1822295-3-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Ming Lei <ming.lei@redhat.com> Cc: Mike Christie <michael.christie@oracle.com> Cc: Hannes Reinecke <hare@suse.de> Cc: John Garry <john.garry@huawei.com> Reviewed-by:
-
Bart Van Assche authored
This commit prevents that the following sequence triggers a kernel crash: - Deletion of a SCSI device is requested via sysfs. Device removal takes some time because blk_cleanup_queue() is waiting for the SCSI error handler. - The SCSI target associated with that SCSI device is removed. - scsi_remove_target() returns and its caller frees the resources associated with the SCSI target. - The error handler makes progress and invokes an LLD callback that dereferences the SCSI target pointer. Link: https://lore.kernel.org/r/20220728221851.1822295-2-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Mike Christie <michael.christie@oracle.com> Cc: Hannes Reinecke <hare@suse.de> Cc: John Garry <john.garry@huawei.com> Cc: Li Zhijian <lizhijian@fujitsu.com> Reported-by:
-
Daniil Lunev authored
dsm_fns is a bitmap, and it is 0-indexed according to the check in __intel_dsm function. But common initialization was checking it as if it was 1-indexed. This patch corrects the discrepancy. This change won't break any existing calls to the function, since before the change both bits 0 and 1 were checked and needed to be set. Link: https://lore.kernel.org/r/20220728111748.v3.1.I22460c4f4a9ccf2c96c3f9bb392b409926d80b2f@changeidReviewed-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Daniil Lunev <dlunev@chromium.org> Signed-off-by:
-
Dmitry Bogdanov authored
se_lun and se_lun_acl are immutable pointers of struct se_dev_entry. Remove RCU usage for access to those pointers. Link: https://lore.kernel.org/r/20220727214125.19647-3-d.bogdanov@yadro.comReviewed-by:
Dmitry Bogdanov <d.bogdanov@yadro.com> Signed-off-by:
-
Dmitry Bogdanov authored
Under huge load there is a possibility of race condition in updating se_dev_entry object in ACL removal procedure: NIP [c0080000154093d0] transport_lookup_cmd_lun+0x1f8/0x3d0 [target_core_mod] LR [c00800001542ab34] target_submit_cmd_map_sgls+0x11c/0x300 [target_core_mod] Call Trace: target_submit_cmd_map_sgls+0x11c/0x300 [target_core_mod] target_submit_cmd+0x44/0x60 [target_core_mod] tcm_qla2xxx_handle_cmd+0x88/0xe0 [tcm_qla2xxx] qlt_do_work+0x2e4/0x3d0 [qla2xxx] process_one_work+0x298/0x5c Despite usage of RCU primitives with deve->se_lun pointer, it has not become dereference-safe because deve->se_lun is updated and not synchronized with a reader. That change might be in a release function called by synchronize_rcu(). But, in fact, there is no point in setting that pointer to NULL for deleting deve. All access to deve->se_lun is already under rcu_read_lock. And either deve->se_lun is always valid or deve is not valid itself and will not be found in the list_for_*. The same applicable for deve->se_lun_acl too. So a better solution is to remove that NULLing. Link: https://lore.kernel.org/r/20220727214125.19647-2-d.bogdanov@yadro.comReviewed-by:
-
Peter Wang authored
After ufshcd_wl_shutdown() set device power off and link off, ufshcd_shutdown() could turn off clock/power. Also remove pm_runtime_get_sync. The reason why it is safe to remove pm_runtime_get_sync() is because: - ufshcd_wl_shutdown() -> pm_runtime_get_sync() will resume hba->dev too. - device resume(turn on clk/power) is not required, even if device is in RPM_SUSPENDED. Link: https://lore.kernel.org/r/20220727030526.31022-1-peter.wang@mediatek.com Fixes: b294ff3e ("scsi: ufs: core: Enable power management for wlun") Cc: <stable@vger.kernel.org> # 5.15.x Reviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
Peter Wang <peter.wang@mediatek.com> Signed-off-by:
-
Bart Van Assche authored
Measurements for one particular UFS controller + UFS device show a 25% higher read bandwidth if the maximum data buffer size is increased from 512 KiB to 1 MiB. Hence increase the maximum size of the data buffer associated with a single request from SCSI_DEFAULT_MAX_SECTORS (1024) * 512 bytes = 512 KiB to 1 MiB. Notes: - The maximum data buffer size supported by the UFSHCI specification is 65535 * 256 KiB or about 16 GiB. - The maximum data buffer size for READ(10) commands is 65535 logical blocks. To transfer more than 65535 * 4096 bytes = 255 MiB with a single SCSI command, the READ(16) command is required. Support for READ(16) is optional in the UFS 3.1 and UFS 4.0 standards. Link: https://lore.kernel.org/r/20220726225232.1362251-1-bvanassche@acm.org Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Avri Altman <avri.altman@wdc.com> Cc: Bean Huo <beanhuo@micron.com> Cc: Stanley Chu <stanley.chu@mediatek.com> Tested-by:
Avri Altman <avri.altman@wdc.com> Acked-by:
-
William Dean authored
The function alloc_workqueue() in lpfc_sli4_driver_resource_setup() can fail, but there is no check of its return value. The return value should be checked. Link: https://lore.kernel.org/r/20220723064027.2956623-1-williamsukatube@163.com Fixes: 3cee98db ("scsi: lpfc: Fix crash on driver unload in wq free") Reported-by:
Hacash Robot <hacashRobot@santino.com> Reviewed-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
William Dean <williamsukatube@gmail.com> Signed-off-by:
-
- 27 Jul, 2022 9 commits
-
-
Mike Christie authored
This patch removes XDWRITEREAD support because it never fully worked when it was added in the initial LIO merge and it's been fully broken since 2013 from commit a2890087 ("target: Add compare_and_write_post() completion callback fall through"). The two issues above are: 1. XDWRITEREAD support was just never completed when LIO was merged. We never did the DISABLE WRITE check and so we never write data out. 2. Since the commit above, we never complete the command. After we do the XOR, we return from xdreadwrite_callback and that's it. We never send a response for the command, so the command will always time out and fail. Since this has been fully broken for almost nine years this patch just removes emulated support. Link: https://lore.kernel.org/r/20220726235339.14551-1-michael.christie@oracle.comSigned-off-by:
-
Jason Wang authored
Initialising global and static variables to 0 is unnecessary. Remove the initialisation. Link: https://lore.kernel.org/r/20220723091620.5463-1-wangborong@cdjrlc.comSigned-off-by:
Jason Wang <wangborong@cdjrlc.com> Signed-off-by:
-
Xin Gao authored
Link: https://lore.kernel.org/r/20220720195229.9109-1-gaoxin@cdjrlc.comSigned-off-by:
Xin Gao <gaoxin@cdjrlc.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_dbg message. Fix it. Link: https://lore.kernel.org/r/20220719110649.759821-1-colin.i.king@gmail.comSigned-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Dmitry Bogdanov authored
RFC7143 states that Initiator decides what type of authentication to use: The initiator MUST continue with: CHAP_N=<N> CHAP_R=<R> or, if it requires target authentication, with: CHAP_N=<N> CHAP_R=<R> CHAP_I=<I> CHAP_C=<C> Allow one way authentication if mutual authentication is configured. That passes some tests from Windows HLK for Mutual CHAP with iSNS. Link: https://lore.kernel.org/r/20220718152555.17084-5-d.bogdanov@yadro.comReviewed-by: -
Dmitry Bogdanov authored
Allow negotiating AuthMethod=None at CSG=0 (Security Negotiation) when authentication is not required. That is required by the CHAP test in Windows HLK. Link: https://lore.kernel.org/r/20220718152555.17084-4-d.bogdanov@yadro.comReviewed-by:
-
Dmitry Bogdanov authored
RFC7143 allows both Base64 and Hex encoding for CHAP binary entities like Challenge and Response. Currently the Linux iSCSI target supports only Hex encoding. Add support for Base64 encoded CHAP Challenge and CHAP Response required for CHAP tests in Windows HLK. Link: https://lore.kernel.org/r/20220718152555.17084-3-d.bogdanov@yadro.comReviewed-by:
-
Dmitry Bogdanov authored
Variable length SCSI commands are transferred over iSCSI via two CDB buffers - in Basic Header Segment and in Additional Header Segment (AHS). Since AHS is not supported yet, a target reads just BHS (48 byte) from TCP and treats the remaining octets as a next new iSCSI PDU that causes protocol errors. Add support for the Extended CDB AHS type. Link: https://lore.kernel.org/r/20220718152555.17084-2-d.bogdanov@yadro.comReviewed-by:
-
Johan Hovold authored
Add SC8280XP to the DT schema. Link: https://lore.kernel.org/r/20220711101441.4896-1-johan+linaro@kernel.orgReviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Signed-off-by:
-
- 19 Jul, 2022 20 commits
-
-
Justin Stitt authored
When building with Clang we encounter these warnings: | drivers/target/iscsi/iscsi_target_login.c:719:24: error: format | specifies type 'unsigned short' but the argument has type 'int' | [-Werror,-Wformat] " from node: %s\n", atomic_read(&sess->nconn), - | drivers/target/iscsi/iscsi_target_login.c:767:12: error: format | specifies type 'unsigned short' but the argument has type 'int' | [-Werror,-Wformat] " %s\n", atomic_read(&sess->nconn), - | drivers/target/iscsi/iscsi_target.c:4365:12: error: format specifies | type 'unsigned short' but the argument has type 'int' [-Werror,-Wformat] | " %s\n", atomic_read(&sess->nconn) For all warnings, the format specifier is '%hu' which describes an unsigned short. The resulting type of atomic_read is an int. The proposed fix is to listen to Clang and swap the format specifier. Link: https://github.com/ClangBuiltLinux/linux/issues/378 Link: https://lore.kernel.org/r/20220718180421.49697-1-justinstitt@google.comReviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by:
Justin Stitt <justinstitt@google.com> Signed-off-by:
-
Daniil Lunev authored
UFS storage devices require bRefClkFreq attribute to be set to operate correctly at high speed mode. The necessary value is determined by what the SoC / board supports. The standard doesn't specify a method to query the value, so the information needs to be fed in separately. DT information feeds into setting up the clock framework, so platforms using DT can get the UFS reference clock frequency from the clock framework. A special node "ref_clk" from the clock array for the UFS controller node is used as the source for the information. On the platforms that do not use DT (e.g. Intel), the alternative mechanism to feed the intended reference clock frequency is necessary. Specifying the necessary information in DSD of the UFS controller ACPI node is an alternative mechanism proposed in this patch. Those can be accessed via firmware property facility in the kernel and in many ways simillar to querying properties defined in DT. This patch introduces a small helper function to query a predetermined ACPI supplied property of the UFS controller, and uses it to attempt retrieving reference clock value, unless that was already done by the clock infrastructure. Link: https://lore.kernel.org/r/20220715210230.1.I365d113d275117dee8fd055ce4fc7e6aebd0bce9@changeidReviewed-by:
-
Xiang Chen authored
Currently if a phy reset or enable phy is issued via sysfs when controller is suspended, those operations will be ignored as SAS_HA_REGISTERED is cleared. If RPM is enabled then we may aggressively suspend automatically. In this case it may be difficult to enable or reset a phy via sysfs, so resume the host in these scenarios. Link: https://lore.kernel.org/r/1657823002-139010-6-git-send-email-john.garry@huawei.comSigned-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Xingui Yang authored
If the I/O completion response frame returned by the target device has been written to the host memory and the err bit in the status field of the received fis is 1, ts->stat should set to SAS_PROTO_RESPONSE, and this will let EH analyze and further determine cause of failure. Link: https://lore.kernel.org/r/1657823002-139010-5-git-send-email-john.garry@huawei.comSigned-off-by:
Xingui Yang <yangxingui@huawei.com> Signed-off-by:
-
Xiang Chen authored
Currently SMP tasks are DMA unmapped only when cq of SMP I/O is returned normally. If the cq of SMP I/O is returned with exception actually SMP TAS is never unmapped. Relocate DMA unmap of SMP task to fix the issue. Link: https://lore.kernel.org/r/1657823002-139010-4-git-send-email-john.garry@huawei.comSigned-off-by:
-
Xiang Chen authored
Use slot->n_elem to store the return value of dma_map_sg() for SSP and SMP IOs, and remove unnecessary variable n_elem_req. Link: https://lore.kernel.org/r/1657823002-139010-3-git-send-email-john.garry@huawei.comSigned-off-by:
-
John Garry authored
There is duplicated code between slave_configure_v3_hw() and hisi_sas_slave_configure(), so call common function hisi_sas_slave_configure() from slave_configure_v3_hw(). Link: https://lore.kernel.org/r/1657823002-139010-2-git-send-email-john.garry@huawei.comSigned-off-by:
-
Dan Carpenter authored
This code is indented one more tab than it should be. Link: https://lore.kernel.org/r/YtVCFshEJNC7ELid@kiliSigned-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
There is some clean up necessary before returning. Smatch complains: drivers/scsi/mpi3mr/mpi3mr_fw.c:4786 mpi3mr_soft_reset_handler() warn: inconsistent returns '&mrioc->reset_mutex'. Locked on : 4730 Unlocked on: 4786 Link: https://lore.kernel.org/r/YtVCEsxMU8buuMjP@kili Fixes: f10af057 ("scsi: mpi3mr: Resource Based Metering") Signed-off-by: -
Sreekanth Reddy authored
Reduce the VD queue depth on detecting the throttling condition. [mkp: incorporate fix for pointer cast issue reported by the test robot and Guenter Roeck] Link: https://lore.kernel.org/r/20220708195020.8323-3-sreekanth.reddy@broadcom.comSigned-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
Update driver to track cumulative pending large data size at the controller level and at the throttle group level. When one of the values meet or exceed the controller's firmware-determined high threshold value, then the driver will divert future selective I/O to the firmware. Once both controller level and at the throttle group level cumulative pending large data size reach controller's firmware determined low threshold value, then the driver will stop diverting I/Os to the firmware. Link: https://lore.kernel.org/r/20220708195020.8323-2-sreekanth.reddy@broadcom.comSigned-off-by:
-
Tony Battersby authored
When a SCSI device is removed while in active use, currently sg will immediately return -ENODEV on any attempt to wait for active commands that were sent before the removal. This is problematic for commands that use SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel when userspace frees or reuses it after getting ENODEV, leading to corrupted userspace memory (in the case of READ-type commands) or corrupted data being sent to the device (in the case of WRITE-type commands). This has been seen in practice when logging out of a iscsi_tcp session, where the iSCSI driver may still be processing commands after the device has been marked for removal. Change the policy to allow userspace to wait for active sg commands even when the device is being removed. Return -ENODEV only when there are no more responses to read. Link: https://lore.kernel.org/r/5ebea46f-fe83-2d0b-233d-d0dcb362dd0a@cybernetics.com Cc: <stable@vger.kernel.org> Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
Tony Battersby <tonyb@cybernetics.com> Signed-off-by:
-
Nilesh Javali authored
Link: https://lore.kernel.org/r/20220713052045.10683-11-njavali@marvell.comReviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
-
Bikash Hazarika authored
Update manufacturer details to indicate Marvell Semiconductors. Link: https://lore.kernel.org/r/20220713052045.10683-10-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by:
Bikash Hazarika <bhazarika@marvell.com> Signed-off-by:
-
Nilesh Javali authored
Use le16_to_cpu to fix sparse warning reported for dport_data. sparse warnings: (new ones prefixed by >>) >> drivers/scsi/qla2xxx/qla_bsg.c:2485:34: sparse: sparse: incorrect >> type in assignment (different base types) @@ expected unsigned >> short [usertype] mbx1 @@ got restricted __le16 @@ drivers/scsi/qla2xxx/qla_bsg.c:2485:34: sparse: expected unsigned short [usertype] mbx1 drivers/scsi/qla2xxx/qla_bsg.c:2485:34: sparse: got restricted __le16 >> drivers/scsi/qla2xxx/qla_bsg.c:2486:34: sparse: sparse: >> incorrect type in assignment (different base types) @@ >> expected unsigned short [usertype] mbx2 @@ got restricted __le16 @@ drivers/scsi/qla2xxx/qla_bsg.c:2486:34: sparse: expected unsigned short [usertype] mbx2 drivers/scsi/qla2xxx/qla_bsg.c:2486:34: sparse: got restricted __le16 Link: https://lore.kernel.org/r/20220713052045.10683-9-njavali@marvell.com Fixes: 476da8fa ("scsi: qla2xxx: Add a new v2 dport diagnostic feature") Cc: stable@vger.kernel.org Reported-by:kernel test robot <lkp@intel.com> Reviewed-by:
-
Arun Easi authored
A direct attach tape device, when gets swapped with another, was not discovered. Fix this by looking at loop map and reinitialize link if there are devices present. Link: https://lore.kernel.org/linux-scsi/baef87c3-5dad-3b47-44c1-6914bfc90108@cybernetics.com/ Link: https://lore.kernel.org/r/20220713052045.10683-8-njavali@marvell.com Cc: stable@vger.kernel.org Reported-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
-
Quinn Tran authored
vref_count took an extra decrement in the task management path. Add an extra ref count to compensate the imbalance. Link: https://lore.kernel.org/r/20220713052045.10683-7-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
-
Quinn Tran authored
This patch fixes IKE message being dropped due to error in processing Purex IOCB and Continuation IOCBs. Link: https://lore.kernel.org/r/20220713052045.10683-6-njavali@marvell.com Fixes: fac28079 ("scsi: qla2xxx: edif: Add extraction of auth_els from the wire") Cc: stable@vger.kernel.org Reviewed-by:
-
Arun Easi authored
On some platforms, the current logic of relying on finding new packet solely based on signature pattern can lead to driver reading stale packets. Though this is a bug in those platforms, reduce such exposures by limiting reading packets until the IN pointer. Two module parameters are introduced: ql2xrspq_follow_inptr: When set, on newer adapters that has queue pointer shadowing, look for response packets only until response queue in pointer. When reset, response packets are read based on a signature pattern logic (old way). ql2xrspq_follow_inptr_legacy: Like ql2xrspq_follow_inptr, but for those adapters where there is no queue pointer shadowing. Link: https://lore.kernel.org/r/20220713052045.10683-5-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by: -
Bikash Hazarika authored
While requesting a new mailbox command, driver does not write any data to unused registers. Initialize the unused register value to zero while requesting a new mailbox command to prevent stale entry access by firmware. Link: https://lore.kernel.org/r/20220713052045.10683-4-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by:
-
