- 03 Jul, 2020 18 commits
-
-
Douglas Gilbert authored
Heavy testing indicates the irqsave() spinlock around the __set_bit() is insufficient to stop following clear_bit() calls being rarely applied out-of-order. Also the nearby failed kzalloc() path leading to SCSI_MLQUEUE_HOST_BUSY does not properly undo the in_use bitmap and num_in_q, fix. Link: https://lore.kernel.org/r/20200702145355.522283-1-dgilbert@interlog.comSigned-off-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Mike Christie authored
Just delete the sess from the session list instead of adding it to some list we never use. Link: https://lore.kernel.org/r/1593632868-6808-4-git-send-email-michael.christie@oracle.comSigned-off-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
-
Mike Christie authored
There is no need for one session to flush the entire iscsi_eh_timer_workq when removing/unblocking a session. During removal we need to make sure our works are not running anymore. And iscsi_unblock_session only needs to make sure its work is done. The unblock work function will flush/cancel the works it has conflicts with. Link: https://lore.kernel.org/r/1593632868-6808-3-git-send-email-michael.christie@oracle.comSigned-off-by:
-
Mike Christie authored
If we are doing async removal of the session, we could be doing a scsi_remove_target from the removal workqueue, and for the offload case we could be doing a new session addition and scan to the same host. The add/scan might then end up trying to use the target_id of the target we are removing. This patch just has a delay the freeing of the target_id until after the scsi_remove_target has completed, so we know it's no longer in use. Link: https://lore.kernel.org/r/1593632868-6808-2-git-send-email-michael.christie@oracle.comReviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
-
Bob Liu authored
Permit scsi_wq_xxx and scsi_tmf_xxx to be bound to different CPUs to get better isolation. Use alloc_workqueue with WQ_SYSFS and drop __WQ_ORDERED_EXPLICIT since a __WQ_ORDERED_EXPLICIT workqueue isn't allowed to change the CPU mask. Link: https://lore.kernel.org/r/20200701030745.16897-2-bob.liu@oracle.comReviewed-by:
Bob Liu <bob.liu@oracle.com> Signed-off-by:
-
Dick Kennedy authored
Update lpfc version to 12.8.0.2 Link: https://lore.kernel.org/r/20200630215001.70793-15-jsmart2021@gmail.comSigned-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
Dick Kennedy authored
The current logging methods typically end up requesting a reproduction with a different logging level set to figure out what happened. This was mainly by design to not clutter the kernel log messages with things that were typically not interesting and the messages themselves could cause other issues. When looking to make a better system, it was seen that in many cases when more data was wanted was when another message, usually at KERN_ERR level, was logged. And in most cases, what the additional logging that was then enabled was typically. Most of these areas fell into the discovery machine. Based on this summary, the following design has been put in place: The driver will maintain an internal log (256 elements of 256 bytes). The "additional logging" messages that are usually enabled in a reproduction will be changed to now log all the time to the internal log. A new logging level is defined - LOG_TRACE_EVENT. When this level is set (it is not by default) and a message marked as KERN_ERR is logged, all the messages in the internal log will be dumped to the kernel log before the KERN_ERR message is logged. There is a timestamp on each message added to the internal log. However, this timestamp is not converted to wall time when logged. The value of the timestamp is solely to give a crude time reference for the messages. Link: https://lore.kernel.org/r/20200630215001.70793-14-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Although the existing implementation is very good at high I/O load, on tests involving light load, especially on only a few hardware queues, latency was a little higher than it can be due to using workqueue scheduling. Other tasks in the system can delay handling. Change the lower level to use irq_poll by default which uses a softirq for I/O completion. This gives better latency as variance in when the cq is processed is reduced over the workqueue interface. However, as high load is better served by not being in softirq when the CPU is loaded, work queues are still used under high I/O load. Link: https://lore.kernel.org/r/20200630215001.70793-13-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Currently, if there has been an issue whereby an adapter dump was taken, there is nothing displayed to hint that it is present. Utilities must be run and they must query for the status in order to then download the dump. Add a message to the driver to query dump image presence when initializing the SLI Port. Link: https://lore.kernel.org/r/20200630215001.70793-12-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Currently the driver validates command codes received from the application. COMMON_SET_FEATURES is not currently being approved. Add definition of the missing command and allow it to be issued by applications. Link: https://lore.kernel.org/r/20200630215001.70793-11-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Change vocabulary of 0373 log msg from "error" to "cmpl" The current language of the 0373 message contains the word "error" which caused a number of customers to inquire about the "error" and if it should be a concern. It isn't an error, it's simply an io completion status. Revise the message to replace the word "error" with "cmpl" for completion. Link: https://lore.kernel.org/r/20200630215001.70793-10-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
When the kdump kernel shuts down lpfc calls flush_work_queue on an interrupt to schedule the cq handler. When there is only one CPU active on the kdump kernel, it is possible for the work_on to get scheduled on a non-active CPU causing it to never be scheduled. When in the kdump environment, per-CPU affinity of cq's to cpus is not necessary. In those cases, use a general queue_work rather than a queue_work_on(). Link: https://lore.kernel.org/r/20200630215001.70793-9-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
When vports are deleted, it is observed that there is memory/kthread leakage as the vport isn't fully being released. There is a shost reference taken in scsi_add_host_dma that is not released during scsi_remove_host. It was noticed that other drivers resolve this by doing a scsi_host_put after calling scsi_remove_host. The vport_delete routine is taking two references one that corresponds to an access to the scsi_host in the vport_delete routine and another that is released after the adapter mailbox command completes that destroys the VPI that corresponds to the vport. Remove one of the references taken such that the second reference that is put will complete the missing scsi_add_host_dma reference and the shost will be terminated. Link: https://lore.kernel.org/r/20200630215001.70793-8-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Call traces have been observed running different tests that involve aborts and setting the rrq active flag. The lpfc_set_rrq_active routine is doing a mempool_alloc under the soft_irq processing level. When the mempool needs to get a new buffer from the free pool and has to wait for memory to become free it will check the flags passed in on the alloc and dump the stack if the thread is running in interrupt context. Replace the GFP_KERNEL flag with GFP_ATOMIC so that the memory allocation will not attempt to sleep if there is no mem available. Link: https://lore.kernel.org/r/20200630215001.70793-7-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
When using DUMP on SLI3 to read VPD and Port status data (config region 23), the adapter is overruning the kmalloc'd buffer causing havoc on other consumers of the allocation pools. Rework the loops processing the dump data and validate/size memory lengths before performing bcopy. Link: https://lore.kernel.org/r/20200630215001.70793-6-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
During driver unload/reload testing, the NVMe initiator would not re-establish connectivity to NVMe controllers on reload. The failing NVMe array supports concurrent FCP and NVMe operation via different nport_id's. The array was repeatedly sending an ADISC every 2 seconds after PLOGI completed and while NVMe subsystems were executing discovery. The target would continue this state for roughly 45 seconds. The driver's current behavior on ADISC receipt is to validate a the ADISC vs the device and issue a RESUME_RPI to restore transmission. The receipt of the ADISC effectively caused a driver to take actions similar to a logout and login for the remote port, causing the deregistration of the nvme rport and a subsequent re-registration. This caused a constant reset and re-connect of the NVMe controller while this 45s window occurred. There was no need for the state changes as ADISC does not change login state. This patch corrects this behavior by validating if the remoteport is already logged in (MAPPED) and when true, avoids the call to set the ndlp state to MAPPED, which triggers the unreg/re-reg. Thus ADISC does not change the login state of the node. Link: https://lore.kernel.org/r/20200630215001.70793-5-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Visual code inspection of the MDS implementation revealed two errors in the driver: - The set features Feature Code had an incorrect value - The routine that classifies command type for cmd completions was missing the Send Frame definition. Send Frame is used for MDS driver loopback. Link: https://lore.kernel.org/r/20200630215001.70793-3-jsmart2021@gmail.comSigned-off-by:
-
Dick Kennedy authored
Coverity reported the following error: Assigned value that is never used may represent unnecessary computation. The rc variable was initially assigned a value but in several cases, when an error case is detected, it is reassigned a new value. The initial value had little use. In code-reviewing this routine, it could use some cleanup: - Setting the initialization value to -ENODEV is a much better choice and lessens code in the routine. - The wasn't tracking logic errors vs no error and mailbox failure. Better to resolve by adding a status to track the mailbox failure and merge it with the logic error when the routine returns. Link: https://lore.kernel.org/r/20200630215001.70793-2-jsmart2021@gmail.comSigned-off-by:
-
- 02 Jul, 2020 2 commits
-
-
Shyam Sundar authored
* Firmware Initialization with SCM enabled based on NVRAM setting and firmware support (About Firmware). * Enable PUREX and add support for fabric performance impact notification (FPIN) handling. * Allocate a default PUREX item for each vha to handle memory allocation failures in ISR. Link: https://lore.kernel.org/r/20200630102229.29660-3-njavali@marvell.comReviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Shyam Sundar <ssundar@marvell.com> Signed-off-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
-
Shyam Sundar authored
SAN Congestion Management generates ELS pkts whose size can vary and be > 64 bytes. Change the PUREX handling code to support non-standard ELS pkt size. Link: https://lore.kernel.org/r/20200630102229.29660-2-njavali@marvell.comReviewed-by:
-
- 01 Jul, 2020 9 commits
-
-
Bart Van Assche authored
Instead of repeating the code for generating a debug message prefix six times, introduce a function for computing the debug message prefix. Link: https://lore.kernel.org/r/20200629225454.22863-10-bvanassche@acm.org Cc: Nilesh Javali <njavali@marvell.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
Daniel Wagner <dwagner@suse.de> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Bart Van Assche authored
Instead of using complicated control flow to only have one return statement at the end of qla2x00_restart_isp(), return an error status as soon as it is known that this function will fail. Link: https://lore.kernel.org/r/20200629225454.22863-9-bvanassche@acm.org Cc: Nilesh Javali <njavali@marvell.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
-
Bart Van Assche authored
'cnt' can exceed the size of the risc_ram[] array. Prevent that Coverity complains by rewriting an address calculation expression. This patch fixes the following Coverity complaint: CID 337803 (#1 of 1): Out-of-bounds read (OVERRUN) 109. overrun-local: Overrunning array of 122880 bytes at byte offset 122880 by dereferencing pointer &fw->risc_ram[cnt]. Link: https://lore.kernel.org/r/20200629225454.22863-8-bvanassche@acm.org Cc: Nilesh Javali <njavali@marvell.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
-
Bart Van Assche authored
The request_t 'handle' member is 32-bits wide, hence use wrt_reg_dword(). Change the cast in the wrt_reg_byte() call to make it clear that a regular pointer is casted to an __iomem pointer. Note: 'pkt' points to I/O memory for the qlafx00 adapter family and to coherent memory for all other adapter families. This patch fixes the following Coverity complaint: CID 358864 (#1 of 1): Reliance on integer endianness (INCOMPATIBLE_CAST) incompatible_cast: Pointer &pkt->handle points to an object whose effective type is unsigned int (32 bits, unsigned) but is dereferenced as a narrower unsigned short (16 bits, unsigned). This may lead to unexpected results depending on machine endianness. Link: https://lore.kernel.org/r/20200629225454.22863-7-bvanassche@acm.org Fixes: 8ae6d9c7 ("[SCSI] qla2xxx: Enhancements to support ISPFx00.") Cc: Nilesh Javali <njavali@marvell.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
-
Bart Van Assche authored
Remove an unnecessary cast because it prevents the compiler to perform type checking. Link: https://lore.kernel.org/r/20200629225454.22863-6-bvanassche@acm.org Cc: Nilesh Javali <njavali@marvell.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
-
Bart Van Assche authored
The following code: qla82xx_rom_fast_read(ha, 0, &n) only initializes 'n' if it succeeds. Since 'n' may be reported in a debug message even if no ROM reads succeeded, initialize 'n' to zero. This patch fixes the following sparse warning: qla_nx.c:1218: qla82xx_pinit_from_rom() error: uninitialized symbol 'n'. Link: https://lore.kernel.org/r/20200629225454.22863-5-bvanassche@acm.org Cc: Nilesh Javali <njavali@marvell.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
-
Bart Van Assche authored
Return early instead of having a single return statement at the end of this function. This patch fixes the following sparse warning: qla_nx.c:1018: qla82xx_flash_wait_write_finish() error: uninitialized symbol 'val'. Link: https://lore.kernel.org/r/20200629225454.22863-4-bvanassche@acm.org Cc: Nilesh Javali <njavali@marvell.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
-
Bart Van Assche authored
Remove the __packed annotation from struct fcp_hdr* because that annotation is not necessary for these data structures. Link: https://lore.kernel.org/r/20200629225454.22863-3-bvanassche@acm.org Cc: Nilesh Javali <njavali@marvell.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
-
Bart Van Assche authored
Since struct fcp_hdr is used to exchange data with the firmware, check its size at compile time. Link: https://lore.kernel.org/r/20200629225454.22863-2-bvanassche@acm.org Cc: Nilesh Javali <njavali@marvell.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
-
- 30 Jun, 2020 2 commits
-
-
Bodo Stroesser authored
If tcmu_handle_completions() has to process a padding shorter than sizeof(struct tcmu_cmd_entry), the current call to tcmu_flush_dcache_range() with sizeof(struct tcmu_cmd_entry) as length param is wrong and causes crashes on e.g. ARM, because tcmu_flush_dcache_range() in this case calls flush_dcache_page(vmalloc_to_page(start)); with start being an invalid address above the end of the vmalloc'ed area. The fix is to use the minimum of remaining ring space and sizeof(struct tcmu_cmd_entry) as the length param. The patch was tested on kernel 4.19.118. See https://bugzilla.kernel.org/show_bug.cgi?id=208045#c10 Link: https://lore.kernel.org/r/20200629093756.8947-1-bstroesser@ts.fujitsu.comTested-by:
JiangYu <lnsyyj@hotmail.com> Acked-by:
Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by:
-
Dan Carpenter authored
The "head" pointer can't be NULL because it points to an address in the middle of a ufs_hba struct. Looking at this code, probably someone would wonder if the intent was to check whether "hba" is NULL, but "hba" isn't NULL and the check can just be removed. Link: https://lore.kernel.org/r/20200626105133.GF314359@mwandaAcked-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 27 Jun, 2020 5 commits
-
-
Flavio Suligoi authored
Fix typo: "trigerred" --> "triggered" Link: https://lore.kernel.org/r/20200624135600.14274-1-f.suligoi@asem.itSigned-off-by:
Flavio Suligoi <f.suligoi@asem.it> Signed-off-by:
-
Stanley Chu authored
If a UFS device is not qualified to use WriteBooster, either due to wrong UFS version or device-specific quirks, then the capability in host shall be disabled to prevent any WriteBooster operations in the future. Link: https://lore.kernel.org/r/20200625030430.25048-1-stanley.chu@mediatek.com Fixes: 3d17b9b5 ("scsi: ufs: Add write booster feature support") Tested-by:
Steev Klimaszewski <steev@kali.org> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
-
Javed Hasan authored
Removed all the unused variables. Link: https://lore.kernel.org/r/20200622093814.3250-1-jhasan@marvell.comReported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Javed Hasan <jhasan@marvell.com> Signed-off-by:
-
Christophe JAILLET authored
The dev_id used in request_irq() and free_irq() should match. Use 'info' in both cases. Link: https://lore.kernel.org/r/20200625204730.943520-1-christophe.jaillet@wanadoo.fr Fixes: 1da177e4 ("Linux-2.6.12-rc2") Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Alim Akhtar authored
While building for x86_64 allmodconfig, the following warning was reported: WARNING: modpost: missing MODULE_LICENSE() in drivers/scsi/ufs/ufs-exynos.o Add the missing license/author/description tags. Link: https://lore.kernel.org/r/20200625154405.60448-1-alim.akhtar@samsung.com Fixes: 55f4b1f7 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 24 Jun, 2020 2 commits
-
-
Wei Yongjun authored
In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Link: https://lore.kernel.org/r/20200618133837.127274-1-weiyongjun1@huawei.com Fixes: 55f4b1f7 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Reported-by:
Hulk Robot <hulkci@huawei.com> Acked-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Alim Akhtar authored
Allow Exynos UFS driver to build as a module. This patch fixes the followin build issue reported by kernel build robot. drivers/scsi/ufs/ufs-exynos.o: in function `exynos_ufs_probe': drivers/scsi/ufs/ufs-exynos.c:1231: undefined reference to `ufshcd_pltfrm_init' drivers/scsi/ufs/ufs-exynos.o: in function `exynos_ufs_pre_pwr_mode': drivers/scsi/ufs/ufs-exynos.c:635: undefined reference to `ufshcd_get_pwr_dev_param' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_shutdown' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_suspend' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_resume' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_runtime_suspend' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_runtime_resume' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_runtime_idle' Link: https://lore.kernel.org/r/20200620173232.52521-1-alim.akhtar@samsung.com Fixes: 55f4b1f7 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Reported-by:
-
- 20 Jun, 2020 2 commits
-
-
Bodo Stroesser authored
This patch fixes the following crash (see https://bugzilla.kernel.org/show_bug.cgi?id=208045) Process iscsi_trx (pid: 7496, stack limit = 0x0000000010dd111a) CPU: 0 PID: 7496 Comm: iscsi_trx Not tainted 4.19.118-0419118-generic #202004230533 Hardware name: Greatwall QingTian DF720/F601, BIOS 601FBE20 Sep 26 2019 pstate: 80400005 (Nzcv daif +PAN -UAO) pc : flush_dcache_page+0x18/0x40 lr : is_ring_space_avail+0x68/0x2f8 [target_core_user] sp : ffff000015123a80 x29: ffff000015123a80 x28: 0000000000000000 x27: 0000000000001000 x26: ffff000023ea5000 x25: ffffcfa25bbe08b8 x24: 0000000000000078 x23: ffff7e0000000000 x22: ffff000023ea5001 x21: ffffcfa24b79c000 x20: 0000000000000fff x19: ffff7e00008fa940 x18: 0000000000000000 x17: 0000000000000000 x16: ffff2d047e709138 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: ffff2d047fbd0a40 x11: 0000000000000000 x10: 0000000000000030 x9 : 0000000000000000 x8 : ffffc9a254820a00 x7 : 00000000000013b0 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffcfa25bbe08e8 x3 : 0000000000001000 x2 : 0000000000000078 x1 : ffffcfa25bbe08b8 x0 : ffff2d040bc88a18 Call trace: flush_dcache_page+0x18/0x40 is_ring_space_avail+0x68/0x2f8 [target_core_user] queue_cmd_ring+0x1f8/0x680 [target_core_user] tcmu_queue_cmd+0xe4/0x158 [target_core_user] __target_execute_cmd+0x30/0xf0 [target_core_mod] target_execute_cmd+0x294/0x390 [target_core_mod] transport_generic_new_cmd+0x1e8/0x358 [target_core_mod] transport_handle_cdb_direct+0x50/0xb0 [target_core_mod] iscsit_execute_cmd+0x2b4/0x350 [iscsi_target_mod] iscsit_sequence_cmd+0xd8/0x1d8 [iscsi_target_mod] iscsit_process_scsi_cmd+0xac/0xf8 [iscsi_target_mod] iscsit_get_rx_pdu+0x404/0xd00 [iscsi_target_mod] iscsi_target_rx_thread+0xb8/0x130 [iscsi_target_mod] kthread+0x130/0x138 ret_from_fork+0x10/0x18 Code: f9000bf3 aa0003f3 aa1e03e0 d503201f (f9400260) ---[ end trace 1e451c73f4266776 ]--- The solution is based on patch: "scsi: target: tcmu: Optimize use of flush_dcache_page" which restricts the use of tcmu_flush_dcache_range() to addresses from vmalloc'ed areas only. This patch now replaces the virt_to_page() call in tcmu_flush_dcache_range() - which is wrong for vmalloced addrs - by vmalloc_to_page(). The patch was tested on ARM with kernel 4.19.118 and 5.7.2 Link: https://lore.kernel.org/r/20200618131632.32748-3-bstroesser@ts.fujitsu.comTested-by:
Daniel Meyerholt <dxm523@gmail.com> Acked-by:
-
Bodo Stroesser authored
(scatter|gather)_data_area() need to flush dcache after writing data to or before reading data from a page in uio data area. The two routines are able to handle data transfer to/from such a page in fragments and flush the cache after each fragment was copied by calling the wrapper tcmu_flush_dcache_range(). That means: 1) flush_dcache_page() can be called multiple times for the same page. 2) Calling flush_dcache_page() indirectly using the wrapper does not make sense, because each call of the wrapper is for one single page only and the calling routine already has the correct page pointer. Change (scatter|gather)_data_area() such that, instead of calling tcmu_flush_dcache_range() before/after each memcpy, it now calls flush_dcache_page() before unmapping a page (when writing is complete for that page) or after mapping a page (when starting to read the page). After this change only calls to tcmu_flush_dcache_range() for addresses in vmalloc'ed command ring are left over. The patch was tested on ARM with kernel 4.19.118 and 5.7.2 Link: https://lore.kernel.org/r/20200618131632.32748-2-bstroesser@ts.fujitsu.comTested-by:
-
