- 23 Feb, 2021 9 commits
-
-
Bodo Stroesser authored
When user deletes a tcmu device via configFS, tcmu calls uio_unregister_device(). During that call uio resets its pointer to struct uio_info provided by tcmu. That means, after uio_unregister_device() uio will no longer execute any of the callbacks tcmu had set in uio_info. Especially, if userspace daemon still holds the corresponding uio device open or mmap'ed while tcmu calls uio_unregister_device(), uio will not call tcmu_release() when userspace finally closes and munmaps the uio device. Since tcmu does refcounting for the tcmu device in tcmu_open() and tcmu_release(), in the decribed case refcount does not drop to 0 and tcmu does not free tcmu device's resources. In extreme cases this can cause memory leaking of up to 1 GB for a single tcmu device. After uio_unregister_device(), uio will reject every open, read, write, mmap from userspace with -EOI. But userspace daemon can still access the mmap'ed command ring and data area. Therefore tcmu should wait until userspace munmaps the uio device before it frees the resources, as we don't want to cause SIGSEGV or SIGBUS to user space. That said, current refcounting during tcmu_open and tcmu_release does not work correctly, and refcounting better should be done in the open and close callouts of the vm_operations_struct, which tcmu assigns to each mmap of the uio device (because it wants its own page fault handler). This patch fixes the memory leak by removing refcounting from tcmu_open and tcmu_close, and instead adding new tcmu_vma_open() and tcmu_vma_close() handlers that only do refcounting. Link: https://lore.kernel.org/r/20210218175039.7829-3-bostroesser@gmail.comReviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Bodo Stroesser <bostroesser@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Bodo Stroesser authored
This patch just moves one block of code containing some functions inside target_core_user.c to avoid adding prototypes in next patch. Link: https://lore.kernel.org/r/20210218175039.7829-2-bostroesser@gmail.comReviewed-by:
-
Johannes Thumshirn authored
Dan reported we're passing in GFP_NOIO to kvmalloc() which will then fallback to doing kmalloc() instead of an optional vmalloc() if the size exceeds kmalloc()s limits. This will break with drives that have zone numbers exceeding PAGE_SIZE/sizeof(u32). Instead of passing in GFP_NOIO, enter an implicit GFP_NOIO allocation scope. Link: https://lore.kernel.org/r/YCuvSfKw4qEQBr/t@mwanda Link: https://lore.kernel.org/r/5a6345e2989fd06c049ac4e4627f6acb492c15b8.1613569821.git.johannes.thumshirn@wdc.com Fixes: 5795eb44: ("scsi: sd_zbc: emulate ZONE_APPEND commands") Cc: Damien Le Moal <Damien.LeMoal@wdc.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
-
Chen Lin authored
Remove the 'ahc_bus_suspend/resume_t' typedef as it is not used. Link: https://lore.kernel.org/r/1613389249-3409-1-git-send-email-chen45464546@163.comSigned-off-by:
Chen Lin <chen.lin5@zte.com.cn> Signed-off-by:
-
Randy Dunlap authored
CNIC depends on MMU, but since 'select' does not follow any dependency chains, SCSI_BNX2X_FCOE also needs to depend on MMU, so that erroneous configs are not generated, which cause build errors in cnic. WARNING: unmet direct dependencies detected for CNIC Depends on [n]: NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_BROADCOM [=y] && PCI [=y] && (IPV6 [=n] || IPV6 [=n]=n) && MMU [=n] Selected by [y]: - SCSI_BNX2X_FCOE [=y] && SCSI_LOWLEVEL [=y] && SCSI [=y] && PCI [=y] && (IPV6 [=n] || IPV6 [=n]=n) && LIBFC [=y] && LIBFCOE [=y] riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L154': cnic.c:(.text+0x1094): undefined reference to `uio_event_notify' riscv64-linux-ld: cnic.c:(.text+0x10bc): undefined reference to `uio_event_notify' riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L1442': cnic.c:(.text+0x96a8): undefined reference to `__uio_register_device' riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L0 ': cnic.c:(.text.unlikely+0x68): undefined reference to `uio_unregister_device' Link: https://lore.kernel.org/r/20210213192428.22537-1-rdunlap@infradead.org Fixes: 853e2bd2 ("[SCSI] bnx2fc: Broadcom FCoE offload driver") Cc: Saurav Kashyap <skashyap@marvell.com> Cc: Javed Hasan <jhasan@marvell.com> Cc: GR-QLogic-Storage-Upstream@marvell.com Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Avri Altman authored
Fixes: 2b2bfc8a ("scsi: ufs: Introduce a quirk to allow only page-aligned sg entries") Link: https://lore.kernel.org/r/20210211104638.292499-1-avri.altman@wdc.comReviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
-
Bhaskar Chowdhury authored
s/verson/version/ Link: https://lore.kernel.org/r/20210209143146.3987352-1-unixbhaskar@gmail.comAcked-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by:
-
Aleksandr Miloserdov authored
TCM buffer length doesn't necessarily equal 8 + ADDITIONAL LENGTH which might be considered an underflow in case of Data-In size being greater than 8 + ADDITIONAL LENGTH. So truncate buffer length to prevent underflow. Link: https://lore.kernel.org/r/20210209072202.41154-3-a.miloserdov@yadro.comReviewed-by:
Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
Aleksandr Miloserdov <a.miloserdov@yadro.com> Signed-off-by:
-
Aleksandr Miloserdov authored
TCM doesn't properly handle underflow case for service actions. One way to prevent it is to always complete command with target_complete_cmd_with_length(), however it requires access to data_sg, which is not always available. This change introduces target_set_cmd_data_length() function which allows to set command data length before completing it. Link: https://lore.kernel.org/r/20210209072202.41154-2-a.miloserdov@yadro.comReviewed-by:
-
- 09 Feb, 2021 19 commits
-
-
Mike Christie authored
The session lock in iscsi_session_chkready() is not needed because when we transition from logged into to another state we will block and/or remove the devices under the session, so no new I/O will be sent to the drivers after the block/remove. I/O that races with the block/removal is cleaned up by the drivers when it handles all outstanding I/O, so this just added an extra lock in the main I/O path. This patch removes the lock like other transport classes. Link: https://lore.kernel.org/r/20210207044608.27585-10-michael.christie@oracle.comReviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
-
Mike Christie authored
__qla4xxx_is_chap_active() just wants to know if a session is online and does not care about why it's not, so this has it use iscsi_is_session_online(). This is not a bug now, but the next patch changes the behavior of iscsi_session_chkready() so this patch just prepares the driver for that change. Link: https://lore.kernel.org/r/20210207044608.27585-9-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If we lose the session then relogin, but the new cmdsn window has shrunk (due to something like an admin changing a setting) we will have the old exp/max_cmdsn values and will never be able to update them. For example, max_cmdsn would be 64, but if on the target the user set the window to be smaller then the target could try to return the max_cmdsn as 32. We will see that new max_cmdsn in the rsp but because it's lower than the old max_cmdsn when the window was larger we will not update it. So this patch has us reset the window values during session cleanup so they can be updated after a new login. Link: https://lore.kernel.org/r/20210207044608.27585-8-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
We are setting the shost's can_queue after we add the host which is too late, because the SCSI midlayer will have allocated the tag set based on the can_queue value at that time. This patch has us use the iscsi_host_get_max_scsi_cmds() helper to figure out the number of SCSI cmds. It also fixes up the template can_queue so it reflects the max SCSI cmds we can support like how other drivers work. Link: https://lore.kernel.org/r/20210207044608.27585-7-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
This patch just breaks out the code that calculates the number of SCSI cmds that will be used for a SCSI session. It also adds a check that we don't go over the host's can_queue value. Link: https://lore.kernel.org/r/20210207044608.27585-6-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
We allocate the iSCSI host workq in iscsi_host_alloc() so iscsi_host_free() should do the destruction. Drivers can then do their error/goto handling and call iscsi_host_free() to clean up what has been allocated in iscsi_host_alloc(). Link: https://lore.kernel.org/r/20210207044608.27585-5-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
The following bug was reported and debugged by wubo40@huawei.com: When testing kernel 4.18 version, NULL pointer dereference problem occurs in iscsi_eh_cmd_timed_out() function. I think this bug in the upstream is still exists. The analysis reasons are as follows: 1) For some reason, I/O command did not complete within the timeout period. The block layer timer works, call scsi_times_out() to handle I/O timeout logic. At the same time the command just completes. 2) scsi_times_out() call iscsi_eh_cmd_timed_out() to process timeout logic. Although there is an NULL judgment for the task, the task has not been released yet now. 3) iscsi_complete_task() calls __iscsi_put_task(). The task reference count reaches zero, the conditions for free task is met, then iscsi_free_task() frees the task, and sets sc->SCp.ptr = NULL. After iscsi_eh_cmd_timed_out() passes the task judgment check, there can still be NULL dereference scenarios. CPU0 CPU3 |- scsi_times_out() |- iscsi_complete_task() | | |- iscsi_eh_cmd_timed_out() |- __iscsi_put_task() | | |- task=sc->SCp.ptr, task is not NUL, check passed |- iscsi_free_task(task) | | | |-> sc->SCp.ptr = NULL | | |- task is NULL now, NULL pointer dereference | | | \|/ \|/ Calltrace: [380751.840862] BUG: unable to handle kernel NULL pointer dereference at 0000000000000138 [380751.843709] PGD 0 P4D 0 [380751.844770] Oops: 0000 [#1] SMP PTI [380751.846283] CPU: 0 PID: 403 Comm: kworker/0:1H Kdump: loaded Tainted: G [380751.851467] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [380751.856521] Workqueue: kblockd blk_mq_timeout_work [380751.858527] RIP: 0010:iscsi_eh_cmd_timed_out+0x15e/0x2e0 [libiscsi] [380751.861129] Code: 83 ea 01 48 8d 74 d0 08 48 8b 10 48 8b 4a 50 48 85 c9 74 2c 48 39 d5 74 [380751.868811] RSP: 0018:ffffc1e280a5fd58 EFLAGS: 00010246 [380751.870978] RAX: ffff9fd1e84e15e0 RBX: ffff9fd1e84e6dd0 RCX: 0000000116acc580 [380751.873791] RDX: ffff9fd1f97a9400 RSI: ffff9fd1e84e1800 RDI: ffff9fd1e4d6d420 [380751.876059] RBP: ffff9fd1e4d49000 R08: 0000000116acc580 R09: 0000000116acc580 [380751.878284] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9fd1e6e931e8 [380751.880500] R13: ffff9fd1e84e6ee0 R14: 0000000000000010 R15: 0000000000000003 [380751.882687] FS: 0000000000000000(0000) GS:ffff9fd1fac00000(0000) knlGS:0000000000000000 [380751.885236] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [380751.887059] CR2: 0000000000000138 CR3: 000000011860a001 CR4: 00000000003606f0 [380751.889308] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [380751.891523] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [380751.893738] Call Trace: [380751.894639] scsi_times_out+0x60/0x1c0 [380751.895861] blk_mq_check_expired+0x144/0x200 [380751.897302] ? __switch_to_asm+0x35/0x70 [380751.898551] blk_mq_queue_tag_busy_iter+0x195/0x2e0 [380751.900091] ? __blk_mq_requeue_request+0x100/0x100 [380751.901611] ? __switch_to_asm+0x41/0x70 [380751.902853] ? __blk_mq_requeue_request+0x100/0x100 [380751.904398] blk_mq_timeout_work+0x54/0x130 [380751.905740] process_one_work+0x195/0x390 [380751.907228] worker_thread+0x30/0x390 [380751.908713] ? process_one_work+0x390/0x390 [380751.910350] kthread+0x10d/0x130 [380751.911470] ? kthread_flush_work_fn+0x10/0x10 [380751.913007] ret_from_fork+0x35/0x40 crash> dis -l iscsi_eh_cmd_timed_out+0x15e xxxxx/drivers/scsi/libiscsi.c: 2062 1970 enum blk_eh_timer_return iscsi_eh_cmd_timed_out(struct scsi_cmnd *sc) { ... 1984 spin_lock_bh(&session->frwd_lock); 1985 task = (struct iscsi_task *)sc->SCp.ptr; 1986 if (!task) { 1987 /* 1988 * Raced with completion. Blk layer has taken ownership 1989 * so let timeout code complete it now. 1990 */ 1991 rc = BLK_EH_DONE; 1992 goto done; 1993 } ... 2052 for (i = 0; i < conn->session->cmds_max; i++) { 2053 running_task = conn->session->cmds[i]; 2054 if (!running_task->sc || running_task == task || 2055 running_task->state != ISCSI_TASK_RUNNING) 2056 continue; 2057 2058 /* 2059 * Only check if cmds started before this one have made 2060 * progress, or this could never fail 2061 */ 2062 if (time_after(running_task->sc->jiffies_at_alloc, 2063 task->sc->jiffies_at_alloc)) <--- 2064 continue; 2065 ... } carsh> struct scsi_cmnd ffff9fd1e6e931e8 struct scsi_cmnd { ... SCp = { ptr = 0x0, <--- iscsi_task this_residual = 0, ... }, } To prevent this, we take a ref to the cmd under the back (completion) lock so if the completion side were to call iscsi_complete_task() on the task while the timer/eh paths are not holding the back_lock it will not be freed from under us. Note that this requires the previous patch, "scsi: libiscsi: Drop taskqueuelock" because bnx2i sleeps in its cleanup_task callout if the cmd is aborted. If the EH/timer and completion path are racing we don't know which path will do the last put. The previous patch moved the operations we needed to do under the forward lock to cleanup_queued_task. Once that has run we can drop the forward lock for the cmd and bnx2i no longer has to worry about if the EH, timer or completion path did the ast put and if the forward lock is held or not since it won't be. Link: https://lore.kernel.org/r/20210207044608.27585-4-michael.christie@oracle.comReported-by:Wu Bo <wubo40@huawei.com> Reviewed-by:
-
Mike Christie authored
The purpose of the taskqueuelock was to handle the issue where a bad target decides to send a R2T and before its data has been sent decides to send a cmd response to complete the cmd. The following patches fix up the frwd/back locks so they are taken from the queue/xmit (frwd) and completion (back) paths again. To get there this patch removes the taskqueuelock which for iSCSI xmit wq based drivers was taken in the queue, xmit and completion paths. Instead of the lock, we just make sure we have a ref to the task when we queue a R2T, and then we always remove the task from the requeue list in the xmit path or the forced cleanup paths. Link: https://lore.kernel.org/r/20210207044608.27585-3-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If iscsi_prep_scsi_cmd_pdu() fails we try to add it back to the cmdqueue, but we leave it partially setup. We don't have functions that can undo the pdu and init task setup. We only have cleanup_task which can clean up both parts. So this has us just fail the cmd and go through the standard cleanup routine and then have the SCSI midlayer retry it like is done when it fails in the queuecommand path. Link: https://lore.kernel.org/r/20210207044608.27585-2-michael.christie@oracle.comReviewed-by:
-
Yang Li authored
This patch removes unneeded return variables. It fixes the following warning detected by coccinelle: ./drivers/scsi/isci/request.c:1483:17-23: Unneeded variable: "status". Return "SCI_SUCCESS" on line 1503 ./drivers/scsi/isci/request.c:2157:17-23: Unneeded variable: "status". Return "SCI_SUCCESS" on line 2177 Link: https://lore.kernel.org/r/1612424915-106608-1-git-send-email-yang.lee@linux.alibaba.comReported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
DooHyun Hwang authored
Print event counter after dumping the event history. Link: https://lore.kernel.org/r/20210203101443.28934-1-dh0421.hwang@samsung.comReviewed-by:
DooHyun Hwang <dh0421.hwang@samsung.com> Signed-off-by:
-
Jiapeng Chong authored
Fix the following coccicheck warnings: ./drivers/scsi/qla2xxx/qla_target.c:984:12-14: WARNING !A || A && B is equivalent to !A || B. Link: https://lore.kernel.org/r/1612319190-111421-1-git-send-email-jiapeng.chong@linux.alibaba.comReported-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Yang Li authored
Eliminate the following coccicheck warning: ./drivers/target/sbp/sbp_target.c:1009:2-3: Unneeded semicolon Link: https://lore.kernel.org/r/1612316992-71443-1-git-send-email-yang.lee@linux.alibaba.comReported-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by:
-
Suganath Prabu S authored
Update driver version to 37.100.00.00. Link: https://lore.kernel.org/r/20210204033724.1345-3-suganath-prabu.subramani@broadcom.comSigned-off-by:
Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Suganath Prabu S authored
When a host trace buffer is released, applications never know for what reason the buffer is released. Add a new IOCTL MPT3ADDNLDIAGQUERY to provide the trigger information due to which the diag buffer is released. Link: https://lore.kernel.org/r/20210204033724.1345-2-suganath-prabu.subramani@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
MPT Fusion adapters can steer completions to individual queues and we now have support for shared host-wide tags in the I/O stack. The addition of the host-wide tags allows us to enable multiqueue support for MPT Fusion adapters. Once host-wise tags are enabled, the CPU hotplug feature is also supported. Allow use of host-wide tags to be disabled through the "host_tagset_enable" module parameter. Once we do not have any major performance regressions using host-wide tags, we will drop the hand-crafted interrupt affinity settings. Performance is meeting expectations. About 3.1M IOPS using 24 Drive SSD on Aero controllers. Link: https://lore.kernel.org/r/20210202095832.23072-1-sreekanth.reddy@broadcom.comReported-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
Currently the driver allocates memory for ReplyPostFree queues in chunks of 16. In resource constrained environments--such as VM with 1 GB RAM and 2 CPUs--memory allocation for ReplyPostFree pools may fail because the driver tries to allocate a memory for 16 ReplyPostFree queues even though the actual number needed is 2. Change the driver to allocate memory for only the actual number of queues needed if the ReplyPostFree queue count is less than 16. Link: https://lore.kernel.org/r/20210201141522.25363-1-sreekanth.reddy@broadcom.comSigned-off-by:
-
Arnd Bergmann authored
Building with 'make W=1' enables -Wpacked-not-aligned, and this warns about pmcraid because of incompatible alignment constraints for pmcraid_passthrough_ioctl_buffer: drivers/scsi/pmcraid.h:1044:1: warning: alignment 1 of 'struct pmcraid_passthrough_ioctl_buffer' is less than 32 [-Wpacked-not-aligned] 1044 | } __attribute__ ((packed)); | ^ drivers/scsi/pmcraid.h:1041:24: warning: 'ioarcb' offset 16 in 'struct pmcraid_passthrough_ioctl_buffer' isn't aligned to 32 [-Wpacked-not-aligned] 1041 | struct pmcraid_ioarcb ioarcb; The inner structure is documented as having 32 byte alignment here, but is starts at a 16 byte offset in the outer structure, so it's never actually aligned, as the outer structure is also marked 'packed'. Lee Jones point this out as one of the last files that need to be changed before the warning can be enabled by default. Change the annotations in a way that avoids the warning but leaves the layout unchanged, by removing the packing on the inner structure and adding it to the outer one. The one-byte request_buffer[] array should have been a flexible array member here, which is how I change it to avoid extra padding from the alignment attribute. Link: https://lore.kernel.org/r/20210204163020.3286210-1-arnd@kernel.org Cc: Lee Jones <lee.jones@linaro.org> Reviewed-by:Lee Jones <lee.jones@linaro.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Damien Le Moal authored
In sd_probe(), print a warning if CONFIG_BLK_DEV_ZONED is disabled and a TYPE_ZBC device is found. While at it, use IS_ENABLED() to test if CONFIG_BLK_DEV_ZONED is enabled instead using of a #ifdef. Link: https://lore.kernel.org/r/20210128055658.530133-1-damien.lemoal@wdc.comSigned-off-by:
-
- 29 Jan, 2021 5 commits
-
-
Lukas Bulwahn authored
Commit 0653c358 ("scsi: Drop gdth driver") fails to update MAINTAINERS. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains: warning: no file matches F: drivers/scsi/gdt* Remove the GDT SCSI DISK ARRAY CONTROLLER DRIVER section as well, as the driver is removed now. Link: https://lore.kernel.org/r/20210129052829.13642-1-lukas.bulwahn@gmail.comSigned-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Can Guo authored
The initialization of clk_scaling.min_gear was removed by mistake. This change adds it back, otherwise clock scaling down would fail. Link: https://lore.kernel.org/r/1611802172-37802-1-git-send-email-cang@codeaurora.org Fixes: 4543d9d7 ("scsi: ufs: Refactor ufshcd_init/exit_clk_scaling/gating()") Reported-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by:
Stanley Chu <stanley.chu@mediatek.com> Reviewed-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
-
Bjorn Helgaas authored
Fix misspellings of "physical". Link: https://lore.kernel.org/r/20210126211248.2920028-1-helgaas@kernel.orgSigned-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
dingsenjie authored
allocted -> allocated Link: https://lore.kernel.org/r/20210126054908.45468-1-dingsenjie@163.comSigned-off-by:
dingsenjie <dingsenjie@yulong.com> Signed-off-by:
-
Jiapeng Zhong authored
Fix the following coccicheck warnings: ./drivers/scsi/qla2xxx/qla_nvme.c:288:24-26: WARNING !A || A && B is equivalent to !A || B. Link: https://lore.kernel.org/r/1611650554-33019-1-git-send-email-abaci-bugfix@linux.alibaba.comReported-by:
Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Signed-off-by:
-
- 27 Jan, 2021 7 commits
-
-
Bjorn Helgaas authored
Fix misspellings of "physical". Link: https://lore.kernel.org/r/20210126210328.2918631-1-helgaas@kernel.orgSigned-off-by:
-
Anastasia Kovaleva authored
According to FCP-4 (9.4.2): If the command requested that data beyond the length specified by the FCP_DL field be transferred, then the device server shall set the FCP_RESID_OVER bit (see 9.5.8) to one in the FCP_RSP IU and: a) process the command normally except that data beyond the FCP_DL count shall not be requested or transferred; b) transfer no data and return CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN COMMAND INFORMATION UNIT; or c) may transfer data and return CHECK CONDITION status with the sense key set to ABORTED COMMAND and the additional sense code set to INVALID FIELD IN COMMAND INFORMATION UNIT. TCM follows b) and transfers no data for residual writes but returns INVALID FIELD IN CDB instead of INVALID FIELD IN COMMAND INFORMATION UNIT. Change the ASCQ to INVALID FIELD IN COMMAND INFORMATION UNIT to meet the standard. Link: https://lore.kernel.org/r/20201203082035.54566-4-a.kovaleva@yadro.comSigned-off-by:
Anastasia Kovaleva <a.kovaleva@yadro.com> Signed-off-by:
-
Anastasia Kovaleva authored
According to RFC 7143 11.4.5.2.: If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the SCSI Response PDU as specified in Section 11.4.5.1. The Residual Count MUST be set to the numerical value of (SPDTL - EDTL). If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the SCSI Response PDU as specified in Section 11.4.5.1. The Residual Count MUST be set to the numerical value of (EDTL - SPDTL). libiscsi has residual write tests that check residual kind and residual amount and all of them (Write10Residuals, Write12Residuals, Write16Residuals) currently fail. One of the reasons why they fail is because target completes write commands with INVALID FIELD IN CDB before setting the Overflow/Underflow bit and residual amount. Set the Overflow/Underflow bit and the residual amount before failing a write to comply with RFC 7143. Link: https://lore.kernel.org/r/20201203082035.54566-3-a.kovaleva@yadro.comSigned-off-by:
-
Roman Bolshakov authored
TCM always fails SBC commands with residuals for 4Kn devices when the command is processed by sbc_parse_cdb(). That prevents residual signalling to the transport driver because residual kind and residual amount aren't set. It also makes residual handling different from 512-byte formatted devices - if there are residuals 512-byte LUN would proceed with command execution while 4K-byte LUN would fail. Link: https://lore.kernel.org/r/20201203082035.54566-2-a.kovaleva@yadro.com Based-on: https://patchwork.kernel.org/project/target-devel/patch/20170523234854.21452-31-bart.vanassche@sandisk.com/Based-on-patch-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Konstantin Vinogradov <k.vinogradov@yadro.com> Signed-off-by:
-
Luo Jiaxing authored
The controller provides trace FIFO DFX tool to assist link fault debugging and link optimization. This tool can be helpful when debugging link faults without SAS analyzers. Each PHY has an independent trace FIFO interface. The user can configure the trace FIFO tool of one PHY by using the following six interfaces: signal_sel: select signal group applies to different scenarios. 0x0: linkrate negotiation 0x1: Host 12G TX train 0x2: Disk 12G TX train 0x3: SAS PHY CTRL DFX 0 0x4: SAS PHY CTRL DFX 1 0x5: SAS PCS DFX other: linkrate negotiation dump_mask: The masked hardware status bit will not be updated. dump_mode: determines how to dump data after trigger signal is generated. 0x0: dump forever 0x1: dump 32 data after trigger signal is generated 0x2: no more dump after trigger signal is generated trigger_mode: determines the trigger mode, level or edge. 0x0: dump when trigger signal changed 0x1: dump when trigger signal's level equal to trigger_level 0x2: dump when trigger signal's level different from trigger_level trigger_level: determines the trigger level. trigger_msk: mask trigger signal The user can get 32-byte values from hardware by reading the rd_data. These values consitute the status record of the hardware at different time points. Link: https://lore.kernel.org/r/1611659068-131975-6-git-send-email-john.garry@huawei.comSigned-off-by:
Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Luo Jiaxing authored
If the controller reset occurs at the same time as driver removal, it may be possible that the interrupts have been released prior to the host softreset, and calling pci_irq_vector() there causes a WARN: WARNING: CPU: 37 PID: 1542 /pci/msi.c:1275 pci_irq_vector+0xc0/0xd0 Call trace: pci_irq_vector+0xc0/0xd0 disable_host_v3_hw+0x58/0x5b0 [hisi_sas_v3_hw] soft_reset_v3_hw+0x40/0xc0 [hisi_sas_v3_hw] hisi_sas_controller_reset+0x150/0x260 [hisi_sas_main] hisi_sas_rst_work_handler+0x3c/0x58 [hisi_sas_main] To fix, flush the driver workqueue prior to releasing the interrupts to ensure any resets have been completed. Link: https://lore.kernel.org/r/1611659068-131975-5-git-send-email-john.garry@huawei.comSigned-off-by:
-
Luo Jiaxing authored
Add a config option to enable debugfs support by default. And if debugfs support is enabled by default, dump count default value is increased to 50 as generally users want something bigger than the current default in that situation. Link: https://lore.kernel.org/r/1611659068-131975-4-git-send-email-john.garry@huawei.comSigned-off-by:
-
