- 22 Jun, 2022 15 commits
-
-
Mike Christie authored
We need the back lock when freeing a task, so we hold it when calling __iscsi_put_task() from the completion path to make it easier and to avoid having to retake it in that path. For iscsi_put_task() we just grabbed it while also doing the decrement on the refcount but it's only really needed if the refcount is zero and we free the task. This modifies iscsi_put_task() to just take the lock when needed then has the xmit path use it. Normally we will then not take the back lock from the xmit path. It will only be rare cases where the network is so fast that we get a response right after we send the header/data. Link: https://lore.kernel.org/r/20220616224557.115234-9-michael.christie@oracle.comReviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Mike Christie authored
We currently require that the back_lock is held when calling the functions that manipulate the iscsi_task refcount. The only reason for this is to handle races where we are handling SCSI-ml EH callbacks and the cmd is completing at the same time the normal completion path is running, and we can't return from the EH callback until the driver has stopped accessing the cmd. Holding the back_lock while also accessing the task->state made it simple to check that a cmd is completing and also get/put a refcount at the same time, and at the time we were not as concerned about performance. The problem is that we don't want to take the back_lock from the xmit path for normal I/O since it causes contention with the completion path if the user has chosen to try and split those paths on different CPUs (in this case abusing the CPUs and ignoring caching improves perf for some uses). Begins to remove the back_lock requirement for iscsi_get/put_task by removing the requirement for the get path. Instead of always holding the back_lock we detect if something has done the last put and is about to call iscsi_free_task(). A subsequent commit will then allow iSCSI code to do the last put on a task and only grab the back_lock if the refcount is now zero and it's going to call iscsi_free_task(). Link: https://lore.kernel.org/r/20220616224557.115234-8-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
Commit 5923d64b ("scsi: libiscsi: Drop taskqueuelock") added an extra task->state because for commit 6f8830f5 ("scsi: libiscsi: add lock around task lists to fix list corruption regression") we didn't know why we ended up with cmds on the list and thought it might have been a bad target sending a response while we were still sending the cmd. We were never able to get a target to send us a response early, because it turns out the bug was just a race in libiscsi/libiscsi_tcp where: 1. iscsi_tcp_r2t_rsp() queues a r2t to tcp_task->r2tqueue. 2. iscsi_tcp_task_xmit() runs iscsi_tcp_get_curr_r2t() and sees we have a r2t. It dequeues it and iscsi_tcp_task_xmit() starts to process it. 3. iscsi_tcp_r2t_rsp() runs iscsi_requeue_task() and puts the task on the requeue list. 4. iscsi_tcp_task_xmit() sends the data for r2t. This is the final chunk of data, so the cmd is done. 5. target sends the response. 6. On a different CPU from #3, iscsi_complete_task() processes the response. Since there was no common lock for the list, the lists/tasks pointers are not fully in sync, so could end up with list corruption. Since it was just a race on our side, remove the extra check and fix up the comments. Link: https://lore.kernel.org/r/20220616224557.115234-7-michael.christie@oracle.comReviewed-by:
Wu Bo <wubo40@huawei.com> Reviewed-by:
-
Mike Christie authored
For software iSCSI, we do a session per host so there is no need to set the target's can_queue since it's the same as the host one. Setting it just results in extra atomic checks in the main I/O path. Link: https://lore.kernel.org/r/20220616224557.115234-6-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If we have more data, set the MSG_SENDPAGE_NOTLAST in case we go down the sendpage path. Link: https://lore.kernel.org/r/20220616224557.115234-5-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
We don't always want to run the recv path from the network softirq because when we have to have multiple sessions sharing the same CPUs, some sessions can eat up the NAPI softirq budget and affect other sessions or users. Allow us to queue the recv handling to the iscsi workqueue so we can have the scheduler/wq code try to balance the work and CPU use across all sessions' worker threads. Note: It wasn't the original intent of the change but a nice side effect is that for some workloads/configs we get a nice performance boost. For a simple read heavy test: fio --direct=1 --filename=/dev/dm-0 --rw=randread --bs=256K --ioengine=libaio --iodepth=128 --numjobs=4 where the iscsi threads, fio jobs, and rps_cpus share CPUs we see a 32% throughput boost. We also see increases for small I/O IOPs tests but it's not as high. Link: https://lore.kernel.org/r/20220616224557.115234-4-michael.christie@oracle.comReviewed-by: -
Mike Christie authored
Add helpers to allow the drivers to run their recv paths from libiscsi's workqueue. Link: https://lore.kernel.org/r/20220616224557.115234-3-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
Rename iscsi_conn_queue_work() to iscsi_conn_queue_xmit() to reflect that it handles queueing of xmits only. Link: https://lore.kernel.org/r/20220616224557.115234-2-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
When the system is shutting down, iscsid is not running so we will not get a response to the ISCSI_ERR_INVALID_HOST error event. The system shutdown will then hang waiting on userspace to remove the session. This has libiscsi force the destruction of the session from the kernel when iscsi_host_remove() is called from a driver's shutdown callout. This fixes a regression added in qedi boot with commit d1f2ce77 ("scsi: qedi: Fix host removal with running sessions") which made qedi use the common session removal function that waits on userspace instead of rolling its own kernel based removal. Link: https://lore.kernel.org/r/20220616222738.5722-7-michael.christie@oracle.com Fixes: d1f2ce77 ("scsi: qedi: Fix host removal with running sessions") Tested-by:
Nilesh Javali <njavali@marvell.com> Reviewed-by:
-
Mike Christie authored
When handling errors that lead to host removal use QEDI_MODE_NORMAL. There is currently no difference in behavior between NORMAL and SHUTDOWN, but in a subsequent commit we will want to know when we are called from the pci_driver shutdown callout vs remove/err_handler so we know when userspace is up. Link: https://lore.kernel.org/r/20220616222738.5722-6-michael.christie@oracle.comTested-by:
-
Mike Christie authored
During qedi shutdown we need to stop the iSCSI layer from sending new nops as pings and from responding to target ones and make sure there is no running connection cleanups. Commit d1f2ce77 ("scsi: qedi: Fix host removal with running sessions") converted the driver to use the libicsi helper to drive session removal, so the above issues could be handled. The problem is that during system shutdown iscsid will not be running so when we try to remove the root session we will hang waiting for userspace to reply. Add a helper that will drive the destruction of sessions like these during system shutdown. Link: https://lore.kernel.org/r/20220616222738.5722-5-michael.christie@oracle.comTested-by:
-
Mike Christie authored
In the next patch we allow drivers to drive session removal during shutdown. In this case iscsid will not be running, so we need to detect bound endpoints and disconnect them. This moves the bound ep check so we now always check. Link: https://lore.kernel.org/r/20220616222738.5722-4-michael.christie@oracle.comTested-by:
-
Mike Christie authored
iscsi_if_stop_conn() is only called from the userspace interface but in a subsequent commit we will want to call it from the kernel interface to allow drivers like qedi to remove sessions from inside the kernel during shutdown. This removes the iscsi_uevent code from iscsi_if_stop_conn() so we can call it in a new helper. Link: https://lore.kernel.org/r/20220616222738.5722-3-michael.christie@oracle.comTested-by:
-
Mike Christie authored
If qla4xxx doesn't remove the connection before the session, the iSCSI class tries to remove the connection for it. We were doing a iscsi_put_conn() in the iter function which is not needed and will result in a use after free because iscsi_remove_conn() will free the connection. Link: https://lore.kernel.org/r/20220616222738.5722-2-michael.christie@oracle.comTested-by:
-
Ren Zhijie authored
If CONFIG_PM_SLEEP is not set. make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-, will fail: drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_vreg_fix_vcc’: drivers/ufs/host/ufs-mediatek.c:688:46: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long unsigned int’ [-Wformat=] snprintf(vcc_name, MAX_VCC_NAME, "vcc-opt%u", res.a1); ~^ ~~~~~~ %lu drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_suspend’: drivers/ufs/host/ufs-mediatek.c:1371:8: error: implicit declaration of function ‘ufshcd_system_suspend’; did you mean ‘ufs_mtk_system_suspend’? [-Werror=implicit-function-declaration] ret = ufshcd_system_suspend(dev); ^~~~~~~~~~~~~~~~~~~~~ ufs_mtk_system_suspend drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_resume’: drivers/ufs/host/ufs-mediatek.c:1386:9: error: implicit declaration of function ‘ufshcd_system_resume’; did you mean ‘ufs_mtk_system_resume’? [-Werror=implicit-function-declaration] return ufshcd_system_resume(dev); ^~~~~~~~~~~~~~~~~~~~ ufs_mtk_system_resume cc1: some warnings being treated as errors The declaration of func "ufshcd_system_suspend()" depends on CONFIG_PM_SLEEP, so the function wrapper ufs_mtk_system_suspend() should wrapped by CONFIG_PM_SLEEP too. Link: https://lore.kernel.org/r/20220619115432.205504-1-renzhijie2@huawei.com Fixes: 3fd23b8d ("scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulators") Reported-by:Hulk Robot <hulkci@huawei.com> Reviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
Ren Zhijie <renzhijie2@huawei.com> Signed-off-by:
-
- 17 Jun, 2022 25 commits
-
-
Max Gurtovoy authored
This function always returns 0. We can make it return void to simplify the code. Also, no caller ever checks the return value of this function. Link: https://lore.kernel.org/r/20220616080210.18531-1-mgurtovoy@nvidia.comReviewed-by:
Max Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by:
-
Stanley Chu authored
Some MediaTek UFS platforms support different VCCQx power rails, for example, both 1.2v and 1.8v VCCQx, in a single kernel image. To optimize the system power consumption, provide a way to disable and release the unused power rail during the device probing. Link: https://lore.kernel.org/r/20220616053725.5681-12-stanley.chu@mediatek.comSigned-off-by:
-
Stanley Chu authored
Support multiple VCC sources in MediaTek UFS platforms. Two options are provided and distinguished by specific device tree attributes as below examples, [Option 1: By numbering] mediatek,ufs-vcc-by-num; vcc-opt1-supply = <&mt6373_vbuck4_ufs>; vcc-opt2-supply = <&mt6363_vemc>; [Option 2: By UFS version] mediatek,ufs-vcc-by-ver; vcc-ufs3-supply = <&mt6373_vbuck4_ufs>; Link: https://lore.kernel.org/r/20220616053725.5681-11-stanley.chu@mediatek.comSigned-off-by:
Alice Chao <alice.chao@mediatek.com> Signed-off-by:
Peter Wang <peter.wang@mediatek.com> Signed-off-by:
-
Stanley Chu authored
Export below regulator functions to allow vendors to customize regulator configuration in their own platforms. int ufshcd_populate_vreg(struct device *dev, const char *name, struct ufs_vreg **out_vreg); int ufshcd_get_vreg(struct device *dev, struct ufs_vreg *vreg); Link: https://lore.kernel.org/r/20220616053725.5681-10-stanley.chu@mediatek.comSigned-off-by: -
Stanley Chu authored
Provide the facility to configure parents of VCCQx power rails as low-power or full-power mode in MediaTek UFS platforms. Link: https://lore.kernel.org/r/20220616053725.5681-9-stanley.chu@mediatek.comSigned-off-by:
-
Stanley Chu authored
Provide flexible number of parameters for UFS SMC calls to be used in a subsequent commit. Link: https://lore.kernel.org/r/20220616053725.5681-8-stanley.chu@mediatek.comSigned-off-by:
-
Peter Wang authored
Allow VCCQ to enter low-power mode, and also remove the restriction of VCC because VCCQ/VCCQ2 can be changed to low-power mode even if VCC stays on while the device is not in active power mode. Link: https://lore.kernel.org/r/20220616053725.5681-7-stanley.chu@mediatek.comReviewed-by:
-
Po-Wen Kao authored
Device regulatrs are allowed to enter low-power mode if neither device is not in active mode, nor VCC does not keep on. Fix this by adding conditions before LPM decision. Link: https://lore.kernel.org/r/20220616053725.5681-6-stanley.chu@mediatek.comReviewed-by:
Po-Wen Kao <powen.kao@mediatek.com> Signed-off-by:
-
Po-Wen Kao authored
Currently the LPM configurations of device regulators may not work since VCC is not disabled yet while ufs_mtk_vreg_set_lpm() is executed. Fix this by changing the timing of invoking ufs_mtk_vreg_set_lpm(). Link: https://lore.kernel.org/r/20220616053725.5681-5-stanley.chu@mediatek.comReviewed-by:
-
CC Chou authored
Some MediaTek SoC chips need special flow for power mode change, especially for chips supporting HS-G5. Enable the workaround by setting the host-specific capability. Link: https://lore.kernel.org/r/20220616053725.5681-4-stanley.chu@mediatek.comReviewed-by:
CC Chou <cc.chou@mediatek.com> Signed-off-by:
Eddie Huang <eddie.huang@mediatek.com> Signed-off-by:
Dennis Yu <tun-yu.yu@mediatek.com> Signed-off-by:
Peter Wang <peter.want@medaitek.com> Signed-off-by:
-
Stanley Chu authored
ADAPT now is added not only for HS Gear4 mode but also higher gears. Fix the logic for higher gears. Link: https://lore.kernel.org/r/20220616053725.5681-3-stanley.chu@mediatek.comReviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Stanley Chu authored
Export ufshcd_uic_change_pwr_mode() to allow vendors to use it for SoC-specific power mode change design limitations. Link: https://lore.kernel.org/r/20220616053725.5681-2-stanley.chu@mediatek.comReviewed-by:
-
Nilesh Javali authored
Link: https://lore.kernel.org/r/20220616053508.27186-12-njavali@marvell.comSigned-off-by:
-
Quinn Tran authored
Clear wait for mailbox interrupt flag to prevent stale mailbox: Feb 22 05:22:56 ltcden4-lp7 kernel: qla2xxx [0135:90:00.1]-500a:4: LOOP UP detected (16 Gbps). Feb 22 05:22:59 ltcden4-lp7 kernel: qla2xxx [0135:90:00.1]-d04c:4: MBX Command timeout for cmd 69, ... To fix the issue, driver needs to clear the MBX_INTR_WAIT flag on purging the mailbox. When the stale mailbox completion does arrive, it will be dropped. Link: https://lore.kernel.org/r/20220616053508.27186-11-njavali@marvell.com Fixes: b6faaaf7 ("scsi: qla2xxx: Serialize mailbox request") Cc: Naresh Bannoth <nbannoth@in.ibm.com> Cc: Kyle Mahlkuch <Kyle.Mahlkuch@ibm.com> Cc: stable@vger.kernel.org Reported-by:
Naresh Bannoth <nbannoth@in.ibm.com> Tested-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
-
Arun Easi authored
FCP-2 devices were not coming back online once they were lost, login retries exhausted, and then came back up. Fix this by accepting RSCN when the device is not online. Link: https://lore.kernel.org/r/20220616053508.27186-10-njavali@marvell.com Fixes: 44c57f20 ("scsi: qla2xxx: Changes to support FCP2 Target") Cc: stable@vger.kernel.org Signed-off-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
-
Arun Easi authored
Add a debug print in the devloss callback. Link: https://lore.kernel.org/r/20220616053508.27186-9-njavali@marvell.comSigned-off-by:
-
Arun Easi authored
FC target disappeared during port perturbation tests due to a race that tramples target state. Fix the issue by adding state checks before proceeding. Link: https://lore.kernel.org/r/20220616053508.27186-8-njavali@marvell.com Fixes: 44c57f20 ("scsi: qla2xxx: Changes to support FCP2 Target") Cc: stable@vger.kernel.org Signed-off-by:
-
Arun Easi authored
When a mix of FCP-2 (tape) and non-FCP-2 targets are present, FCP-2 target state was incorrectly transitioned when both of the targets were gone. Fix this by ignoring state transition for FCP-2 targets. Link: https://lore.kernel.org/r/20220616053508.27186-7-njavali@marvell.com Fixes: 44c57f20 ("scsi: qla2xxx: Changes to support FCP2 Target") Cc: stable@vger.kernel.org Signed-off-by:
-
Arun Easi authored
Ensure SRB is returned during I/O timeout error escalation. If that is not possible fail the escalation path. Following crash stack was seen: BUG: unable to handle kernel paging request at 0000002f56aa90f8 IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx] Call Trace: ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx] ? qla2x00_start_sp+0x116/0x1170 [qla2xxx] ? dma_pool_alloc+0x1d6/0x210 ? mempool_alloc+0x54/0x130 ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx] ? qla_do_work+0x2d/0x40 [qla2xxx] ? process_one_work+0x14c/0x390 Link: https://lore.kernel.org/r/20220616053508.27186-6-njavali@marvell.com Fixes: d7459527 ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Signed-off-by:
-
Quinn Tran authored
For 8G adapters, multi-queue was enabled accidentally. Make sure multi-queue is not enabled. Link: https://lore.kernel.org/r/20220616053508.27186-5-njavali@marvell.com Cc: stable@vger.kernel.org Signed-off-by:
-
Quinn Tran authored
Put adapter into a wind down state if OS does not make any attempt to recover the adapter after PCIe error. Link: https://lore.kernel.org/r/20220616053508.27186-4-njavali@marvell.com Cc: stable@vger.kernel.org Signed-off-by:
-
Bikash Hazarika authored
FW requires minimum 72 bytes buffer size for D_port result. Buffer size 1024 is mentioned in the FW spec so buffer size is increased to 1024. Rewrite the logic to handle START/RESTART command from SDMAPI. Link: https://lore.kernel.org/r/20220616053508.27186-3-njavali@marvell.comSigned-off-by:
Bikash Hazarika <bhazarika@marvell.com> Signed-off-by:
-
Arun Easi authored
Disable printing I/O error messages by default. The messages will be printed only when logging was enabled. Link: https://lore.kernel.org/r/20220616053508.27186-2-njavali@marvell.com Fixes: 8e2d81c6 ("scsi: qla2xxx: Fix excessive messages during device logout") Cc: stable@vger.kernel.org Signed-off-by:
-
Dmitry Bogdanov authored
iscsi_data_xmit() (TX worker) is iterating over the queue of new SCSI commands concurrently with the queue being replenished. Only after the queue is emptied will we start sending pending DataOut PDUs. That leads to DataOut timeout on the target side and to connection reinstatement. Give priority to pending DataOut commands over new commands. Link: https://lore.kernel.org/r/20220607131953.11584-1-d.bogdanov@yadro.comReviewed-by:
Konstantin Shelekhin <k.shelekhin@yadro.com> Reviewed-by:
Dmitry Bogdanov <d.bogdanov@yadro.com> Signed-off-by:
-
Alim Akhtar authored
Rearrange all the unipro and mphy addresses in their increasing order. Link: https://lore.kernel.org/r/20220615121204.16642-3-alim.akhtar@samsung.comReviewed-by:
Chanho Park <chanho61.park@samsung.com> Signed-off-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
-
