Al Viro [Fri, 29 May 2020 23:40:28 +0000 (00:40 +0100)]
scsi: hpsa: hpsa_ioctl(): Tidy up a bit
Link: https://lore.kernel.org/r/20200529234028.46373-4-viro@ZenIV.linux.org.uk
Acked-by: Don Brace <don.brace@microsemi.com>
Tested-by: Don Brace <don.brace@microsemi.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Al Viro [Fri, 29 May 2020 23:40:27 +0000 (00:40 +0100)]
scsi: hpsa: Get rid of compat_alloc_user_space()
No need for building a native struct on kernel stack, copying it to
userland one, then calling hpsa_ioctl() which copies it back into _another_
instance of the same struct.
Link: https://lore.kernel.org/r/20200529234028.46373-3-viro@ZenIV.linux.org.uk
Acked-by: Don Brace <don.brace@microsemi.com>
Tested-by: Don Brace <don.brace@microsemi.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Al Viro [Fri, 29 May 2020 23:40:26 +0000 (00:40 +0100)]
scsi: hpsa: Don't bother with vmalloc for BIG_IOCTL_Command_struct
"BIG" in the name refers to the amount of data being transferred, _not_ the
size of structure itself; it's 140 or 144 bytes (for 32bit and 64bit hosts
resp.). IOCTL_Command_struct is 136 or 144 bytes large...
No point whatsoever turning that into dynamic allocation, let alone vmalloc
one. Just keep it as local variable...
Link: https://lore.kernel.org/r/20200529234028.46373-2-viro@ZenIV.linux.org.uk
Acked-by: Don Brace <don.brace@microsemi.com>
Tested-by: Don Brace <don.brace@microsemi.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Al Viro [Fri, 29 May 2020 23:40:25 +0000 (00:40 +0100)]
scsi: hpsa: Lift {BIG_,}IOCTL_Command_struct copy{in,out} into hpsa_ioctl()
Link: https://lore.kernel.org/r/20200529234028.46373-1-viro@ZenIV.linux.org.uk
Acked-by: Don Brace <don.brace@microsemi.com>
Tested-by: Don Brace <don.brace@microsemi.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Sat, 30 May 2020 14:12:00 +0000 (22:12 +0800)]
scsi: ufs: Remove redundant urgent_bkop_lvl initialization
In ufshcd_probe_hba(), all BKOP SW tracking variables can be reset together
in ufshcd_force_reset_auto_bkops(), thus urgent_bkop_lvl initialization in
the beginning of ufshcd_probe_hba() can be merged into
ufshcd_force_reset_auto_bkops().
Link: https://lore.kernel.org/r/20200530141200.4616-1-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Can Guo [Thu, 28 May 2020 02:24:42 +0000 (19:24 -0700)]
scsi: ufs: Don't update urgent bkops level when toggling auto bkops
Urgent bkops level is used to compare against actual bkops status read from
UFS device. Urgent bkops level is set during initialization and might be
updated in exception event handler during runtime. But it should not be
updated to the actual bkops status every time when auto bkops is toggled.
Otherwise, if urgent bkops level is updated to 0, auto bkops shall always
be kept enabled.
Link: https://lore.kernel.org/r/1590632686-17866-1-git-send-email-cang@codeaurora.org
Fixes:
24366c2afbb0 ("scsi: ufs: Recheck bkops level if bkops is disabled")
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Colin Ian King [Wed, 27 May 2020 11:52:42 +0000 (12:52 +0100)]
scsi: qedf: Remove redundant initialization of variable rc
The variable rc is being initialized with a value that is never read and it
is being updated later with a new value. The initialization is redundant
and can be removed.
Link: https://lore.kernel.org/r/20200527115242.172344-1-colin.king@canonical.com
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Suganath Prabu S [Thu, 28 May 2020 14:56:17 +0000 (10:56 -0400)]
scsi: mpt3sas: Fix memset() in non-RDPQ mode
Fix memset() accessing out of range address when reply_queue count is less
than RDPQ_MAX_INDEX_IN_ONE_CHUNK (i.e. 16) in non-RDPQ mode.
In non-RDPQ mode, the driver allocates a single contiguous pool of size
reply_queue's count * reqly_post_free_sz. But the driver is always
memsetting this pool with size 16 * reqly_post_free_sz. If reply queue
count is less than 16 (i.e. when MSI-X vectors enabled < 16), the driver is
accessing out of range address and this results in 'BUG: unable to handle
kernel paging request at fff0x...x' bug.
Make driver use dma_pool_zalloc() API to allocate and zero the pool.
Link: https://lore.kernel.org/r/20200528145617.27252-1-suganath-prabu.subramani@broadcom.com
Fixes:
8012209eb26b ("scsi: mpt3sas: Handle RDPQ DMA allocation in same 4G region")
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Qiushi Wu [Thu, 28 May 2020 20:13:53 +0000 (15:13 -0500)]
scsi: iscsi: Fix reference count leak in iscsi_boot_create_kobj
kobject_init_and_add() takes reference even when it fails. If this
function returns an error, kobject_put() must be called to properly
clean up the memory associated with the object.
Link: https://lore.kernel.org/r/20200528201353.14849-1-wu000273@umn.edu
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bodo Stroesser [Thu, 28 May 2020 19:31:08 +0000 (21:31 +0200)]
scsi: target: tcmu: Fix size in calls to tcmu_flush_dcache_range
1) If remaining ring space before the end of the ring is smaller then the
next cmd to write, tcmu writes a padding entry which fills the remaining
space at the end of the ring.
Then tcmu calls tcmu_flush_dcache_range() with the size of struct
tcmu_cmd_entry as data length to flush. If the space filled by the
padding was smaller then tcmu_cmd_entry, tcmu_flush_dcache_range() is
called for an address range reaching behind the end of the vmalloc'ed
ring.
tcmu_flush_dcache_range() in a loop calls
flush_dcache_page(virt_to_page(start)); for every page being part of the
range. On x86 the line is optimized out by the compiler, as
flush_dcache_page() is empty on x86.
But I assume the above can cause trouble on other architectures that
really have a flush_dcache_page(). For paddings only the header part of
an entry is relevant due to alignment rules the header always fits in
the remaining space, if padding is needed. So tcmu_flush_dcache_range()
can safely be called with sizeof(entry->hdr) as the length here.
2) After it has written a command to cmd ring, tcmu calls
tcmu_flush_dcache_range() using the size of a struct tcmu_cmd_entry as
data length to flush. But if a command needs many iovecs, the real size
of the command may be bigger then tcmu_cmd_entry, so a part of the
written command is not flushed then.
Link: https://lore.kernel.org/r/20200528193108.9085-1-bstroesser@ts.fujitsu.com
Acked-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Vignesh Raghavendra [Tue, 26 May 2020 10:03:40 +0000 (15:33 +0530)]
scsi: ufs: ti-j721e-ufs: Fix unwinding of pm_runtime changes
Fix unwinding of pm_runtime changes when bailing out of driver probe due to
a failure and also on removal of driver.
Link: https://lore.kernel.org/r/20200526100340.15032-1-vigneshr@ti.com
Fixes:
6979e56cec97 ("scsi: ufs: Add driver for TI wrapper for Cadence UFS IP")
Reported-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dan Carpenter [Thu, 21 May 2020 12:12:21 +0000 (15:12 +0300)]
scsi: cxgb3i: Fix some leaks in init_act_open()
There wasn't any clean up done if cxgb3_alloc_atid() failed and also the
original code didn't release "csk->l2t".
Link: https://lore.kernel.org/r/20200521121221.GA247492@mwanda
Fixes:
6f7efaabefeb ("[SCSI] cxgb3i: change cxgb3i to use libcxgbi")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Chen Tao [Wed, 20 May 2020 09:10:36 +0000 (17:10 +0800)]
scsi: ibmvscsi: Make some functions static
Fix the following warning:
drivers/scsi/ibmvscsi/ibmvscsi.c:2387:12: warning: symbol
'ibmvscsi_module_init' was not declared. Should it be static?
drivers/scsi/ibmvscsi/ibmvscsi.c:2409:13: warning: symbol
'ibmvscsi_module_exit' was not declared. Should it be static?
Link: https://lore.kernel.org/r/20200520091036.247286-1-chentao107@huawei.com
Signed-off-by: Chen Tao <chentao107@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Gabriel Krisman Bertazi [Wed, 20 May 2020 02:29:59 +0000 (22:29 -0400)]
scsi: iscsi: Fix deadlock on recovery path during GFP_IO reclaim
iSCSI suffers from a deadlock in case a management command submitted via
the netlink socket sleeps on an allocation while holding the rx_queue_mutex
if that allocation causes a memory reclaim that writebacks to a failed
iSCSI device. The recovery procedure can never make progress to recover
the failed disk or abort outstanding IO operations to complete the reclaim
(since rx_queue_mutex is locked), thus locking the system.
Nevertheless, just marking all allocations under rx_queue_mutex as GFP_NOIO
(or locking the userspace process with something like PF_MEMALLOC_NOIO) is
not enough, since the iSCSI command code relies on other subsystems that
try to grab locked mutexes, whose threads are GFP_IO, leading to the same
deadlock. One instance where this situation can be observed is in the
backtraces below, stitched from multiple bugs reports, involving the kobj
uevent sent when a session is created.
The root of the problem is not the fact that iSCSI does GFP_IO allocations,
that is acceptable. The actual problem is that rx_queue_mutex has a very
large granularity, covering every unrelated netlink command execution at
the same time as the error recovery path.
The proposed fix leverages the recently added mechanism to stop failed
connections from the kernel, by enabling it to execute even though a
management command from the netlink socket is being run (rx_queue_mutex is
held), provided that the command is known to be safe. It splits the
rx_queue_mutex in two mutexes, one protecting from concurrent command
execution from the netlink socket, and one protecting stop_conn from racing
with other connection management operations that might conflict with it.
It is not very pretty, but it is the simplest way to resolve the deadlock.
I considered making it a lock per connection, but some external mutex would
still be needed to deal with iscsi_if_destroy_conn.
The patch was tested by forcing a memory shrinker (unrelated, but used
bufio/dm-verity) to reclaim iSCSI pages every time
ISCSI_UEVENT_CREATE_SESSION happens, which is reasonable to simulate
reclaims that might happen with GFP_KERNEL on that path. Then, a faulty
hung target causes a connection to fail during intensive IO, at the same
time a new session is added by iscsid.
The following stacktraces are stiches from several bug reports, showing a
case where the deadlock can happen.
iSCSI-write
holding: rx_queue_mutex
waiting: uevent_sock_mutex
kobject_uevent_env+0x1bd/0x419
kobject_uevent+0xb/0xd
device_add+0x48a/0x678
scsi_add_host_with_dma+0xc5/0x22d
iscsi_host_add+0x53/0x55
iscsi_sw_tcp_session_create+0xa6/0x129
iscsi_if_rx+0x100/0x1247
netlink_unicast+0x213/0x4f0
netlink_sendmsg+0x230/0x3c0
iscsi_fail iscsi_conn_failure
waiting: rx_queue_mutex
schedule_preempt_disabled+0x325/0x734
__mutex_lock_slowpath+0x18b/0x230
mutex_lock+0x22/0x40
iscsi_conn_failure+0x42/0x149
worker_thread+0x24a/0xbc0
EventManager_
holding: uevent_sock_mutex
waiting: dm_bufio_client->lock
dm_bufio_lock+0xe/0x10
shrink+0x34/0xf7
shrink_slab+0x177/0x5d0
do_try_to_free_pages+0x129/0x470
try_to_free_mem_cgroup_pages+0x14f/0x210
memcg_kmem_newpage_charge+0xa6d/0x13b0
__alloc_pages_nodemask+0x4a3/0x1a70
fallback_alloc+0x1b2/0x36c
__kmalloc_node_track_caller+0xb9/0x10d0
__alloc_skb+0x83/0x2f0
kobject_uevent_env+0x26b/0x419
dm_kobject_uevent+0x70/0x79
dev_suspend+0x1a9/0x1e7
ctl_ioctl+0x3e9/0x411
dm_ctl_ioctl+0x13/0x17
do_vfs_ioctl+0xb3/0x460
SyS_ioctl+0x5e/0x90
MemcgReclaimerD"
holding: dm_bufio_client->lock
waiting: stuck io to finish (needs iscsi_fail thread to progress)
schedule at
ffffffffbd603618
io_schedule at
ffffffffbd603ba4
do_io_schedule at
ffffffffbdaf0d94
__wait_on_bit at
ffffffffbd6008a6
out_of_line_wait_on_bit at
ffffffffbd600960
wait_on_bit.constprop.10 at
ffffffffbdaf0f17
__make_buffer_clean at
ffffffffbdaf18ba
__cleanup_old_buffer at
ffffffffbdaf192f
shrink at
ffffffffbdaf19fd
do_shrink_slab at
ffffffffbd6ec000
shrink_slab at
ffffffffbd6ec24a
do_try_to_free_pages at
ffffffffbd6eda09
try_to_free_mem_cgroup_pages at
ffffffffbd6ede7e
mem_cgroup_resize_limit at
ffffffffbd7024c0
mem_cgroup_write at
ffffffffbd703149
cgroup_file_write at
ffffffffbd6d9c6e
sys_write at
ffffffffbd6662ea
system_call_fastpath at
ffffffffbdbc34a2
Link: https://lore.kernel.org/r/20200520022959.1912856-1-krisman@collabora.com
Reported-by: Khazhismel Kumykov <khazhy@google.com>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 22 May 2020 08:32:12 +0000 (16:32 +0800)]
scsi: ufs: Fix WriteBooster flush during runtime suspend
Currently UFS host driver promises VCC supply if UFS device needs to do
WriteBooster flush during runtime suspend.
However the UFS specification mentions:
"While the flushing operation is in progress, the device is in Active power
mode."
Therefore UFS host driver needs to promise more: Keep UFS device as "Active
power mode", otherwise UFS device shall not do any flush if device enters
Sleep or PowerDown power mode. Similarly, the same promises shall be
applied if device needs urgent BKOP during runtime suspend.
Fix this by not changing device power mode if WriteBooster flush or urgent
BKOP is required in ufshcd_suspend().
Now, if device finishes its job but is not resumed for a very long time,
system will have unnecessary power drain because VCC is still supplied. A
method to re-check the threshold of keeping VCC supply is required to fix
the power drain. However, the threshold re-check needs to re-activate the
link first because the decision depends on the latest device status.
Also introduce a delayed work to force runtime resume after a certain delay
during runtime suspend. This makes threshold re-check happen natually in
the entry of the next runtime-suspend. The device can continue its
WriteBooster flush or urgent BKOP jobs soon after resumed if device has no
upcoming requests and link enters hibern8 state either by Auto-Hibern8 or
hibern8 during clk-gating scheme. This solution not only prevents power
drain but also makes as much use of time as possible for device's
background jobs.
Link: https://lore.kernel.org/r/20200522083212.4008-5-stanley.chu@mediatek.com
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 22 May 2020 08:32:11 +0000 (16:32 +0800)]
scsi: ufs: Fix index of attributes query for WriteBooster feature
For WriteBooster feature related attributes, the index used by query shall
be LUN ID if LU Dedicated buffer mode is enabled.
Link: https://lore.kernel.org/r/20200522083212.4008-4-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 22 May 2020 08:32:10 +0000 (16:32 +0800)]
scsi: ufs: Allow WriteBooster on UFS 2.2 devices
According to the UFS specification, WriteBooster is officially supported by
UFS 2.2.
Since UFS 2.2 specification has been finalized in JEDEC and such devices
have also showed up in the market, modify the checking rule for
ufshcd_wb_probe() to allow these devices to enable WriteBooster.
Link: https://lore.kernel.org/r/20200522083212.4008-3-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 22 May 2020 08:32:09 +0000 (16:32 +0800)]
scsi: ufs: Remove unnecessary memset for dev_info
The whole UFS host instance has been zero-initialized by scsi_host_alloc(),
thus UFS driver does not need to clear "dev_info" member specifically in
ufshcd_device_params_init().
Simply remove the unnecessary code.
Link: https://lore.kernel.org/r/20200522083212.4008-2-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Jeffrey Hugo [Mon, 25 May 2020 20:41:25 +0000 (13:41 -0700)]
scsi: ufs-qcom: Fix scheduling while atomic issue
ufs_qcom_dump_dbg_regs() uses usleep_range, a sleeping function, but can be
called from atomic context in the following flow:
ufshcd_intr -> ufshcd_sl_intr -> ufshcd_check_errors ->
ufshcd_print_host_regs -> ufshcd_vops_dbg_register_dump ->
ufs_qcom_dump_dbg_regs
This causes a boot crash on the Lenovo Miix 630 when the interrupt is
handled on the idle thread.
Fix the issue by switching to udelay().
Link: https://lore.kernel.org/r/20200525204125.46171-1-jeffrey.l.hugo@gmail.com
Fixes:
9c46b8676271 ("scsi: ufs-qcom: dump additional testbus registers")
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Suganath Prabu S [Fri, 22 May 2020 10:35:58 +0000 (06:35 -0400)]
scsi: mpt3sas: Fix reply queue count in non RDPQ mode
For non RDPQ mode, the driver allocates a single contiguous block of memory
pool for all reply descriptor post queues and passes down a single address
in the ReplyDescriptorPostQueueAddress field of the IOC Init Request
Message to the firmware. So reply_post queue will have only one entry which
holds the address of this single contiguous block of memory pool.
While allocating the reply descriptor post queue pool, driver should loop
only once in non-RDPQ mode. But the driver is looping for
ioc->reply_queue_count number of times even though reply_post queue's queue
depth is only one in non-RDPQ mode. This leads to 'BUG: KASAN:
use-after-free in base_alloc_rdpq_dma_pool'.
The fix is to loop only once while allocating memory for the reply
descriptor post queue in non-RDPQ mode
Fixes:
8012209eb26b ("scsi: mpt3sas: Handle RDPQ DMA allocation in same 4G region")
Link: https://lore.kernel.org/r/20200522103558.5710-1-suganath-prabu.subramani@broadcom.com
Reported-by: Tomas Henzl <thenzl@redhat.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiyu Yang [Mon, 25 May 2020 14:16:24 +0000 (22:16 +0800)]
scsi: lpfc: Fix lpfc_nodelist leak when processing unsolicited event
In order to create or activate a new node, lpfc_els_unsol_buffer() invokes
lpfc_nlp_init() or lpfc_enable_node() or lpfc_nlp_get(), all of them will
return a reference of the specified lpfc_nodelist object to "ndlp" with
increased refcnt.
When lpfc_els_unsol_buffer() returns, local variable "ndlp" becomes
invalid, so the refcount should be decreased to keep refcount balanced.
The reference counting issue happens in one exception handling path of
lpfc_els_unsol_buffer(). When "ndlp" in DEV_LOSS, the function forgets to
decrease the refcnt increased by lpfc_nlp_init() or lpfc_enable_node() or
lpfc_nlp_get(), causing a refcnt leak.
Fix this issue by calling lpfc_nlp_put() when "ndlp" in DEV_LOSS.
Link: https://lore.kernel.org/r/1590416184-52592-1-git-send-email-xiyuyang19@fudan.edu.cn
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dan Carpenter [Sat, 23 May 2020 10:11:29 +0000 (13:11 +0300)]
scsi: target: tcmu: Fix a use after free in tcmu_check_expired_queue_cmd()
The pr_debug() dereferences "cmd" after we already freed it by calling
tcmu_free_cmd(cmd). The debug printk needs to be done earlier.
Link: https://lore.kernel.org/r/20200523101129.GB98132@mwanda
Fixes:
61fb24822166 ("scsi: target: tcmu: Userspace must not complete queued commands")
Reviewed-by: Mike Christie <mchristi@redhat.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Sudhakar Panneerselvam [Fri, 22 May 2020 16:51:57 +0000 (16:51 +0000)]
scsi: vhost: Notify TCM about the maximum sg entries supported per command
vhost-scsi pre-allocates the maximum sg entries per command and if a
command requires more than VHOST_SCSI_PREALLOC_SGLS entries, then that
command is failed by it. This patch lets vhost communicate the max sg limit
when it registers vhost_scsi_ops with TCM. With this change, TCM would
report the max sg entries through "Block Limits" VPD page which will be
typically queried by the SCSI initiator during device discovery. By knowing
this limit, the initiator could ensure the maximum transfer length is less
than or equal to what is reported by vhost-scsi.
Link: https://lore.kernel.org/r/1590166317-953-1-git-send-email-sudhakar.panneerselvam@oracle.com
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Sudhakar Panneerselvam <sudhakar.panneerselvam@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Daniel Wagner [Wed, 20 May 2020 13:08:19 +0000 (15:08 +0200)]
scsi: qla2xxx: Remove return value from qla_nvme_ls()
The function always returns QLA_SUCCESS and the caller qla2x00_start_sp()
doesn't even evalute the return value. So there is no point in returning a
status.
Link: https://lore.kernel.org/r/20200520130819.90625-1-dwagner@suse.de
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Wed, 20 May 2020 04:07:38 +0000 (21:07 -0700)]
scsi: qla2xxx: Remove an unused function
This was detected by building the qla2xxx driver with clang. See also
commit
a9083016a531 ("[SCSI] qla2xxx: Add ISP82XX support").
Link: https://lore.kernel.org/r/20200520040738.1017-1-bvanassche@acm.org
Cc: Arun Easi <aeasi@marvell.com>
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Himanshu Madhani <himanshu.madhani@oracle.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Daniel Wagner <dwagner@suse.de>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bob Liu [Tue, 5 May 2020 01:19:08 +0000 (09:19 +0800)]
scsi: iscsi: Register sysfs for iscsi workqueue
This patch enables setting cpu affinity through "cpumask" for iscsi
workqueues (iscsi_q_xx and iscsi_eh), so as to get performance isolation.
The max number of active worker was changed form 1 to 2, because "cpumask"
of ordered workqueue isn't allowed to change.
Link: https://lore.kernel.org/r/20200505011908.15538-1-bob.liu@oracle.com
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Douglas Gilbert [Wed, 13 May 2020 01:39:43 +0000 (21:39 -0400)]
scsi: scsi_debug: Parser tables and code interaction
This patch is in response to a static analyser report from Dan Carpenter
titled: "[bug report] scsi: scsi_debug: Add per_host_store option". This
code may not clear the static analyzer reports, but may shed light on why
they occur. Amongst other things this driver has a table driven SCSI
command parser which also involves some C code. There are some invariants
between the table entries and the corresponding C code (i.e. the resp_*()
functions) that, if broken, may lead to a NULL dereference. And the report
is valid, at least in the case of the PRE-FETCH command. Alas, that is not
one of the cases that the static analyzer reported.
In this particular corner case: when the fake_rw flag is set and the table
entry for a "store"-accessing command does not have the required F_FAKE_RW
flag set, do the following. Call BUG_ON() in the devip2sip() very close to
a comment block explaining why it was called and how to fix it.
checkpatch.pl complains about the BUG_ON() but there is no reasonable
remedial action that can be taken at run time.
This change allows the code reported by the static analyzer to be
simplified. Comments were also added to the table flags (e.g. F_FAKE_RW)
so developers who add commands might be more inclined to use them
(properly).
Link: https://lore.kernel.org/r/20200513013943.25285-1-dgilbert@interlog.com
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Ye Bin [Mon, 18 May 2020 07:47:32 +0000 (15:47 +0800)]
scsi: core: Refactor scsi_mq_setup_tags function
shost->tag_set is used too many times, introduce temporary parameter
tag_set instead of &shost->tag_set.
Link: https://lore.kernel.org/r/20200518074732.39679-1-yebin10@huawei.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Ye Bin <yebin10@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Ye Bin [Mon, 18 May 2020 07:44:20 +0000 (15:44 +0800)]
scsi: core: Fix incorrect usage of shost_for_each_device
shost_for_each_device(sdev, shost) \
for ((sdev) = __scsi_iterate_devices((shost), NULL); \
(sdev); \
(sdev) = __scsi_iterate_devices((shost), (sdev)))
When terminating shost_for_each_device() iteration with break or return,
scsi_device_put() should be used to prevent stale scsi device references
from being left behind.
Link: https://lore.kernel.org/r/20200518074420.39275-1-yebin10@huawei.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Ye Bin <yebin10@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:12 +0000 (14:17 -0700)]
scsi: qla2xxx: Fix endianness annotations in source files
Fix all endianness complaints reported by sparse (C=2) without affecting
the behavior of the code on little endian CPUs.
Link: https://lore.kernel.org/r/20200518211712.11395-16-bvanassche@acm.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Daniel Wagner <dwagner@suse.de>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:11 +0000 (14:17 -0700)]
scsi: qla2xxx: Fix endianness annotations in header files
Annotate members of FC protocol and firmware dump data structures as big
endian. Annotate members of RISC control structures as little endian.
Annotate mailbox registers as little endian. Annotate the mb[] arrays as
CPU-endian because communication of the mb[] values with the hardware
happens through the readw() and writew() functions. readw() converts from
__le16 to u16 and writew() converts from u16 to __le16. Annotate 'handles'
as CPU-endian because for the firmware these are opaque values.
Link: https://lore.kernel.org/r/20200518211712.11395-15-bvanassche@acm.org
CC: Hannes Reinecke <hare@suse.de>
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:10 +0000 (14:17 -0700)]
scsi: qla2xxx: Use make_handle() instead of open-coding it
Link: https://lore.kernel.org/r/20200518211712.11395-14-bvanassche@acm.org
Cc: Arun Easi <aeasi@marvell.com>
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:09 +0000 (14:17 -0700)]
scsi: qla2xxx: Cast explicitly to uint16_t / uint32_t
Casting a pointer to void * and relying on an implicit cast from void *
to uint16_t or uint32_t suppresses sparse warnings about endianness. Hence
cast explicitly to uint16_t and uint32_t. Additionally, remove superfluous
void * casts.
Link: https://lore.kernel.org/r/20200518211712.11395-13-bvanassche@acm.org
Cc: Arun Easi <aeasi@marvell.com>
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Daniel Wagner <dwagner@suse.de>
Cc: Himanshu Madhani <himanshu.madhani@oracle.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:08 +0000 (14:17 -0700)]
scsi: qla2xxx: Change {RD,WRT}_REG_*() function names from upper case into lower case
This was suggested by Daniel Wagner.
Link: https://lore.kernel.org/r/20200518211712.11395-12-bvanassche@acm.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Arun Easi <aeasi@marvell.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:07 +0000 (14:17 -0700)]
scsi: qla2xxx: Fix the code that reads from mailbox registers
Make the MMIO accessors strongly typed such that the compiler checks
whether the accessor function is used that matches the register width. Fix
those MMIO accesses where another number of bits was read or written than
the size of the register.
Link: https://lore.kernel.org/r/20200518211712.11395-11-bvanassche@acm.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:06 +0000 (14:17 -0700)]
scsi: qla2xxx: Use register names instead of register offsets
Make qla27xx_write_remote_reg() easier to read by using register names
instead of register offsets. The 'pahole' tool has been used to convert
register offsets into register names. See also commit
cbb01c2f2f63 ("scsi:
qla2xxx: Fix MPI failure AEN (8200) handling").
Link: https://lore.kernel.org/r/20200518211712.11395-10-bvanassche@acm.org
Cc: Arun Easi <aeasi@marvell.com>
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:05 +0000 (14:17 -0700)]
scsi: qla2xxx: Change two hardcoded constants into offsetof() / sizeof() expressions
This patch does not change any functionality.
Link: https://lore.kernel.org/r/20200518211712.11395-9-bvanassche@acm.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Arun Easi <aeasi@marvell.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:04 +0000 (14:17 -0700)]
scsi: qla2xxx: Increase the size of struct qla_fcp_prio_cfg to FCP_PRIO_CFG_SIZE
This patch fixes the following Coverity complaint without changing any
functionality:
CID 337793 (#1 of 1): Wrong size argument (SIZEOF_MISMATCH)
suspicious_sizeof: Passing argument ha->fcp_prio_cfg of type
struct qla_fcp_prio_cfg * and argument 32768UL to function memset is
suspicious because a multiple of sizeof (struct qla_fcp_prio_cfg) /*48*/
is expected.
memset(ha->fcp_prio_cfg, 0, FCP_PRIO_CFG_SIZE);
Link: https://lore.kernel.org/r/20200518211712.11395-8-bvanassche@acm.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:03 +0000 (14:17 -0700)]
scsi: qla2xxx: Make a gap in struct qla2xxx_offld_chain explicit
This patch makes struct qla2xxx_offld_chain compatible with ARCH=i386.
Link: https://lore.kernel.org/r/20200518211712.11395-7-bvanassche@acm.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Arun Easi <aeasi@marvell.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:02 +0000 (14:17 -0700)]
scsi: qla2xxx: Add more BUILD_BUG_ON() statements
Before fixing the endianness annotations in data structures, make the
compiler verify the size of FC protocol and firmware data structures.
Link: https://lore.kernel.org/r/20200518211712.11395-6-bvanassche@acm.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:01 +0000 (14:17 -0700)]
scsi: qla2xxx: Sort BUILD_BUG_ON() statements alphabetically
Before adding more BUILD_BUG_ON() statements, sort the existing statements
alphabetically.
Link: https://lore.kernel.org/r/20200518211712.11395-5-bvanassche@acm.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Arun Easi <aeasi@marvell.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:17:00 +0000 (14:17 -0700)]
scsi: qla2xxx: Simplify the functions for dumping firmware
Instead of passing an argument to the firmware dumping functions that tells
these functions whether or not to obtain the hardware lock, obtain that
lock before calling these functions. This patch fixes the following
recently introduced C=2 build error:
CHECK drivers/scsi/qla2xxx/qla_tmpl.c
drivers/scsi/qla2xxx/qla_tmpl.c:1133:1: error: Expected ; at end of statement
drivers/scsi/qla2xxx/qla_tmpl.c:1133:1: error: got }
drivers/scsi/qla2xxx/qla_tmpl.h:247:0: error: Expected } at end of function
drivers/scsi/qla2xxx/qla_tmpl.h:247:0: error: got end-of-input
Link: https://lore.kernel.org/r/20200518211712.11395-4-bvanassche@acm.org
Fixes:
cbb01c2f2f63 ("scsi: qla2xxx: Fix MPI failure AEN (8200) handling")
Cc: Arun Easi <aeasi@marvell.com>
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Himanshu Madhani <himanshu.madhani@oracle.com>
Cc: Martin Wilck <mwilck@suse.com>
Cc: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:16:59 +0000 (14:16 -0700)]
scsi: qla2xxx: Suppress two recently introduced compiler warnings
Suppress the following two compiler warnings because these are not useful:
In file included from ./include/trace/define_trace.h:102,
from ./include/trace/events/qla.h:39,
from drivers/scsi/qla2xxx/qla_dbg.c:77:
./include/trace/events/qla.h: In function 'trace_event_raw_event_qla_log_event':
./include/trace/trace_events.h:691:9: warning: function 'trace_event_raw_event_qla_log_event' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format]
691 | struct trace_event_raw_##call *entry; \
| ^~~~~~~~~~~~~~~~
./include/trace/events/qla.h:12:1: note: in expansion of macro 'DECLARE_EVENT_CLASS'
12 | DECLARE_EVENT_CLASS(qla_log_event,
| ^~~~~~~~~~~~~~~~~~~
In file included from ./include/trace/define_trace.h:103,
from ./include/trace/events/qla.h:39,
from drivers/scsi/qla2xxx/qla_dbg.c:77:
./include/trace/events/qla.h: In function 'perf_trace_qla_log_event':
./include/trace/perf.h:41:9: warning: function 'perf_trace_qla_log_event' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format]
41 | struct hlist_head *head; \
| ^~~~~~~~~~
./include/trace/events/qla.h:12:1: note: in expansion of macro 'DECLARE_EVENT_CLASS'
Link: https://lore.kernel.org/r/20200518211712.11395-3-bvanassche@acm.org
Fixes:
598a90f2002c ("scsi: qla2xxx: add ring buffer for tracing debug logs")
Cc: Rajan Shanmugavelu <rajan.shanmugavelu@oracle.com>
Cc: Joe Jin <joe.jin@oracle.com>
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Arun Easi <aeasi@marvell.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Mon, 18 May 2020 21:16:58 +0000 (14:16 -0700)]
scsi: qla2xxx: Fix spelling of a variable name
Change "offet" into "offset" in a variable name.
Link: https://lore.kernel.org/r/20200518211712.11395-2-bvanassche@acm.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Quinn Tran <qutran@marvell.com>
Cc: Martin Wilck <mwilck@suse.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Arun Easi <aeasi@marvell.com>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bodo Stroesser [Mon, 18 May 2020 16:48:33 +0000 (18:48 +0200)]
scsi: target: tcmu: Userspace must not complete queued commands
When tcmu queues a new command - no matter whether in command ring or in
qfull_queue - a cmd_id from IDR udev->commands is assigned to the command.
If userspace sends a wrong command completion containing the cmd_id of a
command on the qfull_queue, tcmu_handle_completions() finds the command in
the IDR and calls tcmu_handle_completion() for it. This might do some nasty
things because commands in qfull_queue do not have a valid dbi list.
To fix this bug, we no longer add queued commands to the idr. Instead the
cmd_id is assign when a command is written to the command ring.
Due to this change I had to adapt the source code at several places where
up to now an idr_for_each had been done.
[mkp: fix checkpatch warnings]
Link: https://lore.kernel.org/r/20200518164833.12775-1-bstroesser@ts.fujitsu.com
Acked-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Lance Digby [Mon, 18 May 2020 01:02:16 +0000 (11:02 +1000)]
scsi: target: core: Add initiatorname to NON_EXISTENT_LUN error
The NON_EXISTENT_LUN error can be written without an error condition
on the initiator responsible. Adding the initiatorname to this message
will reduce the effort required to fix this when many initiators are
supported by a target.
This version ensures the initiator name is also printed on the same message
in transport_lookup_tmr_lun for consistency.
Link: https://lore.kernel.org/r/9b13bb2e1f52f1792cd81850ee95bf3781bb5363.1589759816.git.lance.digby@gmail.com
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Lance Digby <lance.digby@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
John Garry [Fri, 15 May 2020 14:13:45 +0000 (22:13 +0800)]
scsi: hisi_sas: Stop returning error code from slot_complete_vX_hw()
The error codes are never checked, stop returning them.
Link: https://lore.kernel.org/r/1589552025-165012-5-git-send-email-john.garry@huawei.com
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Luo Jiaxing [Fri, 15 May 2020 14:13:44 +0000 (22:13 +0800)]
scsi: hisi_sas: Add SAS_RAS_INTR0 to debugfs register name list
Register SAS_RAS_INTR0 can help us to figure out which ECC error has
occurred. This register is helpful to identify RAS issue, so we add it to
the list of debugfs register name list for easier retrieval.
Link: https://lore.kernel.org/r/1589552025-165012-4-git-send-email-john.garry@huawei.com
Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Luo Jiaxing [Fri, 15 May 2020 14:13:43 +0000 (22:13 +0800)]
scsi: hisi_sas: Modify the commit information for DSM method
Make it clear that BIOS may modify some register settings.
Link: https://lore.kernel.org/r/1589552025-165012-3-git-send-email-john.garry@huawei.com
Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Luo Jiaxing [Fri, 15 May 2020 14:13:42 +0000 (22:13 +0800)]
scsi: hisi_sas: Do not reset phy timer to wait for stray phy up
We found out that after phy up, the hardware reports another oob interrupt
but did not follow a phy up interrupt:
oob ready -> phy up -> DEV found -> oob read -> wait phy up -> timeout
We run link reset when wait phy up timeout, and it send a normal disk into
reset processing. So we made some circumvention action in the code, so that
this abnormal oob interrupt will not start the timer to wait for phy up.
Link: https://lore.kernel.org/r/1589552025-165012-2-git-send-email-john.garry@huawei.com
Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Damien Le Moal [Fri, 15 May 2020 05:48:56 +0000 (14:48 +0900)]
scsi: sd: Add zoned capabilities device attribute
Export through sysfs as a scsi_disk attribute the zoned capabilities of a
disk ("zoned_cap" attribute file). This new attribute indicates in human
readable form (i.e. a string) the zoned block capabilities implemented by
the disk as found in the ZONED field of the disk block device
characteristics VPD page. The possible values are:
- "none": ZONED=00b (not reported), regular disk
- "host-aware": ZONED=01b, host-aware ZBC disk
- "drive-managed": ZONED=10b, drive-managed ZBC disk (regular disk
interface)
For completeness, also add the following value which is detected using the
device type rather than the ZONED field:
- "host-managed": device type = 0x14 (TYPE_ZBC), host-managed ZBC disk
This new sysfs attribute is purely informational and complementary to the
"zoned" device request queue sysfs attribute as it allows applications and
user daemons (e.g. udev) to easily differentiate regular disks from
drive-managed SMR disks without the need for direct access tools such as
provided by sg3utils.
Link: https://lore.kernel.org/r/20200515054856.1408575-1-damien.lemoal@wdc.com
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche [Thu, 7 May 2020 22:27:50 +0000 (15:27 -0700)]
scsi: ufs: Make ufshcd_wait_for_register() sleep instead of busy-waiting
The ufshcd_wait_for_register() function either sleeps or spins until the
specified register has reached the desired value. Busy-waiting is not only
considered a bad practice but also has a bad impact on energy
consumption. Always sleep instead of spinning by making sure that all
ufshcd_wait_for_register() calls happen from a context where it is allowed
to sleep. The only function call that has to be moved is the
ufshcd_hba_stop() call in ufshcd_host_reset_and_restore().
Link: https://lore.kernel.org/r/20200507222750.19113-1-bvanassche@acm.org
Cc: Can Guo <cang@codeaurora.org>
Cc: Avri Altman <avri.altman@wdc.com>
Cc: Bean Huo <beanhuo@micron.com>
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Cc: Asutosh Das <asutoshd@codeaurora.org>
Tested-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Wei Yongjun [Tue, 28 Apr 2020 14:18:55 +0000 (14:18 +0000)]
scsi: cxlflash: Fix error return code in cxlflash_probe()
Fix to return negative error code -ENOMEM from create_afu error handling
case instead of 0, as done elsewhere in this function.
Link: https://lore.kernel.org/r/20200428141855.88704-1-weiyongjun1@huawei.com
Acked-by: Matthew R. Ochs <mrochs@linux.ibm.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Sat, 9 May 2020 09:37:16 +0000 (17:37 +0800)]
scsi: ufs-mediatek: Customize WriteBooster flush policy
Change the WriteBooster policy to keep VCC on during runtime suspend if
available WriteBooster buffer is less than 80%.
Link: https://lore.kernel.org/r/20200509093716.21010-5-stanley.chu@mediatek.com
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Sat, 9 May 2020 09:37:15 +0000 (17:37 +0800)]
scsi: ufs: Customize flush threshold for WriteBooster
Allow flush threshold for WriteBooster to be customizable by vendors. To
achieve this, make the value a variable in struct ufs_hba_variant_params.
Also introduce UFS_WB_BUF_REMAIN_PERCENT() macro to provide a more flexible
way to specify WriteBooster available buffer values.
Link: https://lore.kernel.org/r/20200509093716.21010-4-stanley.chu@mediatek.com
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Sat, 9 May 2020 09:37:13 +0000 (17:37 +0800)]
scsi: ufs: Introduce ufs_hba_variant_params to group customizable parameters
The UFS driver is growing more and more customizable parameters. Collect
them in one place.
Link: https://lore.kernel.org/r/20200509093716.21010-2-stanley.chu@mediatek.com
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Damien Le Moal [Thu, 14 May 2020 08:19:53 +0000 (17:19 +0900)]
scsi: sd: Signal drive managed SMR disks
Print a message indicating that a disk is a drive-managed SMR model when
such drive is found using the ZONED field of the Block Device
Characteristics VPD page (IDENTIFY data on ATA side).
[mkp: typo]
Link: https://lore.kernel.org/r/20200514081953.1252087-1-damien.lemoal@wdc.com
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
ChenTao [Thu, 14 May 2020 01:26:55 +0000 (09:26 +0800)]
scsi: ufs-mediatek: Make ufs_mtk_fixup_dev_quirks static
Fix the following warning:
drivers/scsi/ufs/ufs-mediatek.c:585:6: warning:
symbol 'ufs_mtk_fixup_dev_quirks' was not declared. Should it be static?
Link: https://lore.kernel.org/r/20200514012655.127202-1-chentao107@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: ChenTao <chentao107@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dan Carpenter [Wed, 13 May 2020 09:37:03 +0000 (12:37 +0300)]
scsi: aacraid: Fix an oops in error handling
If the memdup_user() function fails then it results in an Oops in the
error handling code when we try to kfree() and error pointer.
Link: https://lore.kernel.org/r/20200513093703.GB347693@mwanda
Fixes:
8d925b1f00e6 ("scsi: aacraid: Use memdup_user() as a cleanup")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Jason Yan [Tue, 12 May 2020 11:32:58 +0000 (19:32 +0800)]
scsi: hisi_sas: Display proc_name in sysfs
The 'proc_name' entry in sysfs for hisi_sas is 'null' now because it is not
initialized in scsi_host_template. It looks like:
[root@localhost ~]# cat /sys/class/scsi_host/host2/proc_name
(null)
While the other driver's entry looks like:
linux-vnMQMU:~ # cat /sys/class/scsi_host/host0/proc_name
megaraid_sas
Link: https://lore.kernel.org/r/20200512113258.30781-1-yanaijie@huawei.com
Cc: John Garry <john.garry@huawei.com>
Cc: Xiang Chen <chenxiang66@hisilicon.com>
Acked-by: John Garry <john.garry@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dan Carpenter [Sat, 9 May 2020 10:04:08 +0000 (13:04 +0300)]
scsi: scsi_debug: Fix an error handling bug in sdeb_zbc_model_str()
This test is checking the wrong variable. It should be testing "res".
The "sdeb_zbc_model" variable is an enum (unsigned in this situation)
and we never assign negative values to it.
[mkp: fixed commit desc issue reported by Doug]
Link: https://lore.kernel.org/r/20200509100408.GA5555@mwanda
Fixes:
9267e0eb41fe ("scsi: scsi_debug: Add ZBC module parameter")
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Benjamin Block [Fri, 8 May 2020 17:23:35 +0000 (19:23 +0200)]
scsi: zfcp: Move allocation of the shost object to after xconf- and xport-data
At the moment we allocate and register the Scsi_Host object corresponding
to a zfcp adapter (FCP device) very early in the life cycle of the adapter
- even before we fully discover and initialize the underlying
firmware/hardware. This had the advantage that we could already use the
Scsi_Host object, and fill in all its information during said discover and
initialize.
Due to commit
737eb78e82d5 ("block: Delay default elevator initialization")
(first released in v5.4), we noticed a regression that would prevent us
from using any storage volume if zfcp is configured with support for DIF or
DIX (zfcp.dif=1 || zfcp.dix=1). Doing so would result in an illegal memory
access as soon as the first request is sent with such an configuration. As
example for a crash resulting from this:
scsi host0: scsi_eh_0: sleeping
scsi host0: zfcp
qdio: 0.0.1900 ZFCP on SC 4bd using AI:1 QEBSM:0 PRI:1 TDD:1 SIGA: W AP
scsi 0:0:0:0: scsi scan: INQUIRY pass 1 length 36
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address:
0000000000000000 TEID:
0000000000000483
Fault in home space mode while using kernel ASCE.
AS:
0000000035c7c007 R3:
00000001effcc007 S:
00000001effd1000 P:
000000000000003d
Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: ...
CPU: 1 PID: 783 Comm: kworker/u760:5 Kdump: loaded Not tainted 5.6.0-rc2-bb-next+ #1
Hardware name: ...
Workqueue: scsi_wq_0 fc_scsi_scan_rport [scsi_transport_fc]
Krnl PSW :
0704e00180000000 000003ff801fcdae (scsi_queue_rq+0x436/0x740 [scsi_mod])
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS:
0fffffffffffffff 0000000000000000 0000000187150120 0000000000000000
000003ff80223d20 000000000000018e 000000018adc6400 0000000187711000
000003e0062337e8 00000001ae719000 0000000187711000 0000000187150000
00000001ab808100 0000000187150120 000003ff801fcd74 000003e0062336a0
Krnl Code:
000003ff801fcd9e:
e310a35c0012 lt %r1,860(%r10)
000003ff801fcda4:
a7840010 brc 8,
000003ff801fcdc4
#
000003ff801fcda8:
e310b2900004 lg %r1,656(%r11)
>
000003ff801fcdae:
d71710001000 xc 0(24,%r1),0(%r1)
000003ff801fcdb4:
e310b2900004 lg %r1,656(%r11)
000003ff801fcdba:
41201018 la %r2,24(%r1)
000003ff801fcdbe:
e32010000024 stg %r2,0(%r1)
000003ff801fcdc4:
b904002b lgr %r2,%r11
Call Trace:
[<
000003ff801fcdae>] scsi_queue_rq+0x436/0x740 [scsi_mod]
([<
000003ff801fcd74>] scsi_queue_rq+0x3fc/0x740 [scsi_mod])
[<
00000000349c9970>] blk_mq_dispatch_rq_list+0x390/0x680
[<
00000000349d1596>] blk_mq_sched_dispatch_requests+0x196/0x1a8
[<
00000000349c7a04>] __blk_mq_run_hw_queue+0x144/0x160
[<
00000000349c7ab6>] __blk_mq_delay_run_hw_queue+0x96/0x228
[<
00000000349c7d5a>] blk_mq_run_hw_queue+0xd2/0xe0
[<
00000000349d194a>] blk_mq_sched_insert_request+0x192/0x1d8
[<
00000000349c17b8>] blk_execute_rq_nowait+0x80/0x90
[<
00000000349c1856>] blk_execute_rq+0x6e/0xb0
[<
000003ff801f8ac2>] __scsi_execute+0xe2/0x1f0 [scsi_mod]
[<
000003ff801fef98>] scsi_probe_and_add_lun+0x358/0x840 [scsi_mod]
[<
000003ff8020001c>] __scsi_scan_target+0xc4/0x228 [scsi_mod]
[<
000003ff80200254>] scsi_scan_target+0xd4/0x100 [scsi_mod]
[<
000003ff802d8b96>] fc_scsi_scan_rport+0x96/0xc0 [scsi_transport_fc]
[<
0000000034245ce8>] process_one_work+0x458/0x7d0
[<
00000000342462a2>] worker_thread+0x242/0x448
[<
0000000034250994>] kthread+0x15c/0x170
[<
0000000034e1979c>] ret_from_fork+0x30/0x38
INFO: lockdep is turned off.
Last Breaking-Event-Address:
[<
000003ff801fbc36>] scsi_add_cmd_to_list+0x9e/0xa8 [scsi_mod]
Kernel panic - not syncing: Fatal exception: panic_on_oops
While this issue is exposed by the commit named above, this is only by
accident. The real issue exists for longer already - basically since it's
possible to use blk-mq via scsi-mq, and blk-mq pre-allocates all requests
for a tag-set during initialization of the same. For a given Scsi_Host
object this is done when adding the object to the midlayer
(`scsi_add_host()` and such). In `scsi_mq_setup_tags()` the midlayer
calculates how much memory is required for a single scsi_cmnd, and its
additional data, which also might include space for additional protection
data - depending on whether the Scsi_Host has any form of protection
capabilities (`scsi_host_get_prot()`).
The problem is now thus, because zfcp does this step before we actually
know whether the firmware/hardware has these capabilities, we don't set any
protection capabilities in the Scsi_Host object. And so, no space is
allocated for additional protection data for requests in the Scsi_Host
tag-set.
Once we go through discover and initialize the FCP device firmware/hardware
fully (this is done via the firmware commands "Exchange Config Data" and
"Exchange Port Data") we find out whether it actually supports DIF and DIX,
and we set the corresponding capabilities in the Scsi_Host object (in
`zfcp_scsi_set_prot()`). Now the Scsi_Host potentially has protection
capabilities, but the already allocated requests in the tag-set don't have
any space allocated for that.
When we then trigger target scanning or add scsi_devices manually, the
midlayer will use requests from that tag-set, and before sending most
requests, it will also call `scsi_mq_prep_fn()`. To prepare the scsi_cmnd
this function will check again whether the used Scsi_Host has any
protection capabilities - and now it potentially has - and if so, it will
try to initialize the assumed to be preallocated structures and thus it
causes the crash, like shown above.
Before delaying the default elevator initialization with the commit named
above, we always would also allocate an elevator for any scsi_device before
ever sending any requests - in contrast to now, where we do it after
device-probing. That elevator in turn would have its own tag-set, and that
is initialized after we went through discovery and initialization of the
underlying firmware/hardware. So requests from that tag-set can be
allocated properly, and if used - unless the user changes/disabled the
default elevator - this would hide the underlying issue.
To fix this for any configuration - with or without an elevator - we move
the allocation and registration of the Scsi_Host object for a given FCP
device to after the first complete discovery and initialization of the
underlying firmware/hardware. By doing that we can make all basic
properties of the Scsi_Host known to the midlayer by the time we call
`scsi_add_host()`, including whether we have any protection capabilities.
To do that we have to delay all the accesses that we would have done in the
past during discovery and initialization, and do them instead once we are
finished with it. The previous patches ramp up to this by fencing and
factoring out all these accesses, and make it possible to re-do them later
on. In addition we make also use of the diagnostic buffers we recently
added with
commit
92953c6e0aa7 ("scsi: zfcp: signal incomplete or error for sync exchange config/port data")
commit
7e418833e689 ("scsi: zfcp: diagnostics buffer caching and use for exchange port data")
commit
088210233e6f ("scsi: zfcp: add diagnostics buffer for exchange config data")
(first released in v5.5), because these already cache all the information
we need for that "re-do operation" - the information cached are always
updated during xconf or xport data, so it won't be stale.
In addition to the move and re-do, this patch also updates the
function-documentation of `zfcp_scsi_adapter_register()` and changes how it
reports if a Scsi_Host object already exists. In that case future
recovery-operations can skip this step completely and behave much like they
would do in the past - zfcp does not release a once allocated Scsi_Host
object unless the corresponding FCP device is deconstructed completely.
Link: https://lore.kernel.org/r/030dd6da318bbb529f0b5268ec65cebcd20fc0a3.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Benjamin Block [Fri, 8 May 2020 17:23:34 +0000 (19:23 +0200)]
scsi: zfcp: Fence early sysfs interfaces for accesses of shost objects
When setting an adapter online for the first time, we also create a couple
of entries for it in the sysfs device tree. This is also true even if the
adapter has not yet ever gone successfully through exchange config and
exchange port data.
When moving the scsi host object allocation and registration to after the
first exchange config and exchange port data, this make the `port_rescan`
attribute susceptible to invalid pointer-dereferences of the shost field
before the adapter is fully initialized.
When written to, it schedules a `scan_work` item that will in turn make use
of the associated fibre channel host object to check the topology used for
this FCP device.
Because scanning for remote ports can't be done successfully without
completing exchange config and exchange port data first, we can simply
fence `port_rescan`, and so prevent the illegal access.
As with cases where we can't get a reference to the adapter, we also return
-ENODEV here. Applications need to handle that errno today already.
After a successful allocation of the scsi host object nothing changes in
the work flow.
Link: https://lore.kernel.org/r/ef65366d309993ca91b6917727590ca7ca166c8f.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Benjamin Block [Fri, 8 May 2020 17:23:33 +0000 (19:23 +0200)]
scsi: zfcp: Fence adapter status propagation for common statuses
Common status flags that all main objects - adapter, port, and unit -
support are propagated to sub-objects when set or cleared. For instance,
when setting the status ZFCP_STATUS_COMMON_ERP_INUSE for an adapter object,
we will propagate this to all its child ports and units - same for when
clearing a common status flag.
Units of an adapter object are enumerated via __shost_for_each_device()
over the scsi host object of the corresponding adapter.
Once we move the scsi host object allocation and registration to after the
first exchange config and exchange port data, this won't be possible for
cases where we set or clear common statuses during the very first adapter
recovery.
But since we won't have any port or unit objects yet at that point of time,
we can just fence the status propagation for cases where the scsi host
object is not yet set in the adapter object. It won't change any effective
status propagations, but will prevent us from dereferencing invalid
pointers.
For any later point in the work flow the scsi host object will be set and
thus nothing is changed then.
Link: https://lore.kernel.org/r/f51fe5f236a1e3d1ce53379c308777561bfe35e1.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Benjamin Block [Fri, 8 May 2020 17:23:32 +0000 (19:23 +0200)]
scsi: zfcp: Move p-t-p port allocation to after xport data
When doing the very first adapter recovery - initialization - for a FCP
device in a point-to-point topology we also allocate the port object
corresponding to the attached remote port, and trigger a port recovery for
it that will run after the adapter recovery finished.
Right now this happens right after we finished with the exchange config
data command, and uses the fibre channel host object corresponding to the
FCP device to determine whether a point-to-point topology is used.
When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, this use of the fc_host object is not
possible anymore at that point in the work flow.
But the allocation and recovery trigger doesn't have notable side-effects
on the following exchange port data processing, so we can move those to
after xport data, and thus also to after the scsi host object allocation,
once we move it. Then the fc_host object can be used again, like it is now.
For any further adapter recoveries this doesn't change anything, because at
that point the port object already exists and recovery is triggered
elsewhere for existing port objects.
Link: https://lore.kernel.org/r/73e5d4ac21e2b37bf0c3ca8e530bc5a5c6e74f8f.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Benjamin Block [Fri, 8 May 2020 17:23:31 +0000 (19:23 +0200)]
scsi: zfcp: Fence fc_host updates during link-down handling
When receiving a notification that a FCP device lost its local link we
usually update the fibre channel host object which represents that FCP
device to reflect that.
This notification/information can also surface when the FCP device is
running through adapter recovery (exchange config and exchange port data
return incomplete).
When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, and this happens during the very first
adapter recovery, these updates can not be done until after the scsi host
object is allocated.
Reorder the fc_host updates in zfcp_fsf_fc_host_link_down() so that they
only happen after a check of whether the scsi host object is already
allocated or not.
During the first adapter recovery this will cause the skip of these updates
if a link-down condition is detected, but we can repeat them after we
allocated the scsi host object, if necessary.
For any further link-down handling the only changes in the work flow are
the slightly reordered assignments in zfcp_fsf_fc_host_link_down().
Link: https://lore.kernel.org/r/f841f2cda61dcd7b8549910c44e1831927459edf.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Benjamin Block [Fri, 8 May 2020 17:23:30 +0000 (19:23 +0200)]
scsi: zfcp: Move fc_host updates during xport data handling into fenced function
When executing exchange port data for a FCP device for the first time, or
after an adapter recovery, we update several properties of the fibre
channel host object which represents that FCP device.
When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, this is not possible for the former case.
Move all these update into separate, and fenced function that first checks
whether the scsi host object already exists or not, before making the
updates.
During the first ever exchange port data in the adapter life cycle this
will make the exchange port data handler skip over this update step, but we
can repeat it later, after we allocated the scsi host object.
For any further recovery of that adapter the work flow is only changed
slightly because then the scsi host object already exists and we don't free
it until we release the adapter completely at the end of its life cycle.
Link: https://lore.kernel.org/r/ae454c2dc6da0b02907c489af91d0b211d331825.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Benjamin Block [Fri, 8 May 2020 17:23:29 +0000 (19:23 +0200)]
scsi: zfcp: Move shost updates during xconfig data handling into fenced function
When executing exchange config data for a FCP device for the first time, or
after an adapter recovery, we update several properties of the scsi host or
fibre channel host object that represent that FCP device.
When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, this is not possible for the former case.
Move all these update into separate, and fenced function that first checks
whether the scsi host object already exists or not, before making the
updates.
During the first ever exchange config data in the adapter life cycle this
will make the exchange config data handler skip over this update step, but
we can repeat it later, after we allocated the scsi host object.
For any further recovery of that adapter the work flow is only changed
slightly because then the scsi host object already exists and we don't free
it until we release the adapter completely at the end of its life cycle.
Link: https://lore.kernel.org/r/5fc3f4d38d4334f7aa595497c6f7865fb1102e0f.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Benjamin Block [Fri, 8 May 2020 17:23:28 +0000 (19:23 +0200)]
scsi: zfcp: Move shost modification after QDIO (re-)open into fenced function
When establishing and activating the QDIO queue pair for a FCP device for
the first time, or after an adapter recovery, we publish some of its
characteristics to the scsi host object representing that FCP device.
When moving the scsi host object allocation and registration to after the
first exchange config and exchange port data, this is not possible for the
former case - QDIO open for the first time - because that happens before
exchange config and exchange port data.
Move the scsi host object update into a fenced function that checks whether
the object already exists or not. This way we can repeat that step later,
once we are past the allocation.
Once the first recovery succeeds we don't release the scsi host object
anymore, so further recoveries do work as before.
Link: https://lore.kernel.org/r/a214ebf508f71e3690113e3e90edab1cea0e24e3.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Samuel Zou [Fri, 8 May 2020 11:49:33 +0000 (19:49 +0800)]
scsi: mpt3sas: Remove unused including <linux/version.h>
Fix the following versioncheck warning:
drivers/scsi/mpt3sas/mpt3sas_debugfs.c:16:1: unused including <linux/version.h>
Link: https://lore.kernel.org/r/1588938573-57847-1-git-send-email-zou_wei@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Suganath Prabu S [Fri, 8 May 2020 11:07:38 +0000 (07:07 -0400)]
scsi: mpt3sas: Fix double free warnings
Fix following warning from Smatch static analyser:
drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools()
warn: 'ioc->hpr_lookup' double freed
drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools()
warn: 'ioc->internal_lookup' double freed
Link: https://lore.kernel.org/r/20200508110738.30732-1-suganath-prabu.subramani@broadcom.com
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Chandrakanth Patil [Fri, 8 May 2020 08:53:14 +0000 (14:23 +0530)]
scsi: megaraid_sas: Update driver version to 07.714.04.00-rc1
Link: https://lore.kernel.org/r/20200508085314.23461-1-chandrakanth.patil@broadcom.com
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Sumit Saxena [Fri, 8 May 2020 08:52:42 +0000 (14:22 +0530)]
scsi: megaraid_sas: TM command refire leads to controller firmware crash
When TM command times out, driver invokes the controller reset. Post reset,
driver re-fires pended TM commands which leads to firmware crash.
Post controller reset, return pended TM commands back to OS.
Link: https://lore.kernel.org/r/20200508085242.23406-1-chandrakanth.patil@broadcom.com
Cc: stable@vger.kernel.org
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Shivasharan S [Fri, 8 May 2020 08:51:30 +0000 (14:21 +0530)]
scsi: megaraid_sas: Replace undefined MFI_BIG_ENDIAN macro with __BIG_ENDIAN_BITFIELD macro
MFI_BIG_ENDIAN macro used in drivers structure bitfield to check the CPU
big endianness is undefined which would break the code on big endian
machine. __BIG_ENDIAN_BITFIELD kernel macro should be used in places of
MFI_BIG_ENDIAN macro.
Link: https://lore.kernel.org/r/20200508085130.23339-1-chandrakanth.patil@broadcom.com
Fixes:
a7faf81d7858 ("scsi: megaraid_sas: Set no_write_same only for Virtual Disk")
Cc: <stable@vger.kernel.org> # v5.6+
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com>
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Sumit Saxena [Fri, 8 May 2020 08:38:35 +0000 (14:08 +0530)]
scsi: megaraid_sas: Remove IO buffer hole detection logic
As blk_queue_virt_boundary() API in slave_configure ensures that no IOs
will come with holes/gaps. Hence, code logic to detect the holes/gaps in IO
buffer is not required.
Link: https://lore.kernel.org/r/20200508083838.22778-3-chandrakanth.patil@broadcom.com
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Kashyap Desai [Fri, 8 May 2020 08:38:34 +0000 (14:08 +0530)]
scsi: megaraid_sas: Limit device queue depth to controller queue depth
The driver currently assigns a pre-defined queue depth when the
firmware-provided device queue depth is greater than the controller queue
depth.
Use the controller queue depth if the reported target queue depth is too
large.
Link: https://lore.kernel.org/r/20200508083838.22778-2-chandrakanth.patil@broadcom.com
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 8 May 2020 08:01:15 +0000 (16:01 +0800)]
scsi: ufs: Cleanup WriteBooster feature
Small cleanup as below items,
1. Use ufshcd_is_wb_allowed() directly instead of ufshcd_wb_sup() since
ufshcd_wb_sup() just returns the result of ufshcd_is_wb_allowed().
2. In ufshcd_suspend(), "else if (!ufshcd_is_runtime_pm(pm_op)) can be
simplified to "else" since both have the same meaning.
This patch does not change any functionality.
Link: https://lore.kernel.org/r/20200508080115.24233-9-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 8 May 2020 08:01:14 +0000 (16:01 +0800)]
scsi: ufs-mediatek: Enable WriteBooster capability
Enable WriteBooster capability on MediaTek UFS platforms.
Link: https://lore.kernel.org/r/20200508080115.24233-8-stanley.chu@mediatek.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 8 May 2020 08:01:13 +0000 (16:01 +0800)]
scsi: ufs: Add LU Dedicated buffer mode support for WriteBooster
According to UFS specification, there are two WriteBooster mode of
operations: "LU dedicated buffer" mode and "shared buffer" mode. In the
"LU dedicated buffer" mode, the WriteBooster Buffer is dedicated to a
logical unit.
If the device supports the "LU dedicated buffer" mode, this mode is
configured by setting bWriteBoosterBufferType to 00h. The logical unit
WriteBooster Buffer size is configured by setting the
dLUNumWriteBoosterBufferAllocUnits field of the related Unit
Descriptor. Only a value greater than zero enables the WriteBooster feature
in the logical unit.
Modify ufshcd_wb_probe() as above description to support LU Dedicated
buffer mode.
Note that according to UFS 3.1 specification, the valid value of
bDeviceMaxWriteBoosterLUs parameter in Geometry Descriptor is 1, which
means at most one LUN can have WriteBooster buffer in "LU dedicated buffer
mode". Therefore this patch supports only one LUN with WriteBooster
enabled. All WriteBooster related sysfs nodes are specifically mapped to
the LUN with WriteBooster enabled in LU Dedicated buffer mode.
Link: https://lore.kernel.org/r/20200508080115.24233-7-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 8 May 2020 08:01:12 +0000 (16:01 +0800)]
scsi: ufs: Add "index" in parameter list of ufshcd_query_flag()
For preparation of LU Dedicated buffer mode support on WriteBooster
feature, "index" parameter shall be added and allowed to be specified by
callers.
Link: https://lore.kernel.org/r/20200508080115.24233-6-stanley.chu@mediatek.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Can Guo <cang@codeaurora.org>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 8 May 2020 08:01:11 +0000 (16:01 +0800)]
scsi: ufs-mediatek: Add fixup_dev_quirks vops
Add fixup_dev_quirk vops in MediaTek UFS platforms and provide an initial
vendor-specific device quirk table.
Link: https://lore.kernel.org/r/20200508080115.24233-5-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 8 May 2020 08:01:10 +0000 (16:01 +0800)]
scsi: ufs: Export ufs_fixup_device_setup() function
Export ufs_fixup_device_setup() to allow vendors to re-use it for fixing
device quriks on specified UFS hosts.
Link: https://lore.kernel.org/r/20200508080115.24233-4-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 8 May 2020 08:01:09 +0000 (16:01 +0800)]
scsi: ufs: Introduce fixup_dev_quirks vops
Some UFS deivces may have required device quirks or have non-standard
features which are enabled only on specified UFS hosts or for special
customers.
To not "pollute" common device quirk list, i.e. ufs_fixups table, for those
devices mentioned above, introduce "fixup_dev_quirks" vops to allow vendors
to fix or modify device quirks accordingly.
Link: https://lore.kernel.org/r/20200508080115.24233-3-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stanley Chu [Fri, 8 May 2020 08:01:08 +0000 (16:01 +0800)]
scsi: ufs: Enable WriteBooster on some pre-3.1 UFS devices
The WriteBooster feature can be supported by some pre-3.1 UFS devices by
upgrading firmware.
To enable WriteBooster feature in such devices, introduce a device quirk to
relax the entrance condition of ufshcd_wb_probe() to allow host driver to
check those devices' WriteBooster capability.
WriteBooster feature can be available if below all conditions are
satisfied,
1. Host enables WriteBooster capability
2. UFS 3.1 device or UFS pre-3.1 device with quirk
UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES enabled
3. The device descriptor shall have DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP
field
4. WriteBooster support is specified in above field
Link: https://lore.kernel.org/r/20200508080115.24233-2-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Colin Ian King [Thu, 7 May 2020 20:31:11 +0000 (21:31 +0100)]
scsi: lpfc: Remove redundant initialization to variable rc
The variable rc is being initialized with a value that is never read and it
is being updated later with a new value. The initialization is redundant
and can be removed.
Link: https://lore.kernel.org/r/20200507203111.64709-1-colin.king@canonical.com
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Addresses-Coverity: ("Unused value")
Gustavo A. R. Silva [Thu, 7 May 2020 19:25:50 +0000 (14:25 -0500)]
scsi: ufs: Replace zero-length array with flexible-array
The current codebase makes use of the zero-length array language extension
to the C90 standard, but the preferred mechanism to declare variable-length
types such as these ones is a flexible array member[1][2], introduced in
C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning in
case the flexible array does not occur last in the structure, which will
help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this
change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in which
the sizeof operator is being incorrectly/erroneously applied to zero-length
arrays and the result is zero. Such instances may be hiding some bugs. So,
this work (flexible-array member conversions) will also help to get
completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Link: https://lore.kernel.org/r/20200507192550.GA16683@embeddedor
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Gustavo A. R. Silva [Thu, 7 May 2020 19:21:47 +0000 (14:21 -0500)]
scsi: libsas: Replace zero-length array with flexible-array
The current codebase makes use of the zero-length array language extension
to the C90 standard, but the preferred mechanism to declare variable-length
types such as these ones is a flexible array member[1][2], introduced in
C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning in
case the flexible array does not occur last in the structure, which will
help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this
change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in which
the sizeof operator is being incorrectly/erroneously applied to zero-length
arrays and the result is zero. Such instances may be hiding some bugs. So,
this work (flexible-array member conversions) will also help to get
completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Link: https://lore.kernel.org/r/20200507192147.GA16206@embeddedor
Reviewed-by: John Garry <john.garry@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xie XiuQi [Tue, 5 May 2020 12:19:04 +0000 (20:19 +0800)]
scsi: qedi: Remove unused variable udev & uctrl
uctrl and udev are unused after commit
9632a6b4b747 ("scsi: qedi: Move LL2
producer index processing in BH.")
Remove them.
Link: https://lore.kernel.org/r/20200505121904.25702-1-xiexiuqi@huawei.com
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Jason Yan [Tue, 5 May 2020 07:38:07 +0000 (15:38 +0800)]
scsi: bfa: Make bfad_iocmd_ioc_get_stats() static
Fix the following sparse warning:
drivers/scsi/bfa/bfad_bsg.c:140:1: warning: symbol
'bfad_iocmd_ioc_get_stats' was not declared. Should it be static?
Link: https://lore.kernel.org/r/20200505073807.40332-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bodo Stroesser [Tue, 28 Apr 2020 18:26:17 +0000 (20:26 +0200)]
scsi: target: loopback: Fix READ with data and sensebytes
We use tcm_loop with tape emulations running on tcmu.
In case application reads a short tape block with a longer READ, or a long
tape block with a short READ, according to SCC spec data has to be
tranferred _and_ sensebytes with ILI set and information field containing
the residual count. Similar problem also exists when using fixed block
size in READ.
Up to now tcm_loop is not prepared to handle sensebytes if input data is
provided, as in tcm_loop_queue_data_in() it only sets SAM_STAT_GOOD and, if
necessary, the residual count.
To fix the bug, the same handling for sensebytes as present in
tcm_loop_queue_status() must be done in tcm_loop_queue_data_in() also.
After adding this handling, the two function now are nearly identical, so I
created a single function with two wrappers.
Link: https://lore.kernel.org/r/20200428182617.32726-1-bstroesser@ts.fujitsu.com
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Zou Wei [Sun, 26 Apr 2020 02:42:44 +0000 (10:42 +0800)]
scsi: aacraid: Use memdup_user() as a cleanup
Fix coccicheck warning which recommends to use memdup_user().
This patch fixes the following coccicheck warning:
drivers/scsi/aacraid/commctrl.c:516:15-22: WARNING opportunity for memdup_user
Link: https://lore.kernel.org/r/1587868964-75969-1-git-send-email-zou_wei@huawei.com
Fixes:
4645df1035b3 ("[PATCH] aacraid: swapped kmalloc args.")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dick Kennedy [Fri, 1 May 2020 21:43:10 +0000 (14:43 -0700)]
scsi: lpfc: Update lpfc version to 12.8.0.1
Update lpfc version to 12.8.0.1
Link: https://lore.kernel.org/r/20200501214310.91713-10-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dick Kennedy [Fri, 1 May 2020 21:43:09 +0000 (14:43 -0700)]
scsi: lpfc: Fix MDS Diagnostic Enablement definition
The MDS diagnostic enablement bit for the adapter interface is incorrect in
the driver header.
Correct the bit position for the SET_FEATURE MDS bit.
Link: https://lore.kernel.org/r/20200501214310.91713-9-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dick Kennedy [Fri, 1 May 2020 21:43:08 +0000 (14:43 -0700)]
scsi: lpfc: Fix noderef and address space warnings
Running make C=1 M=drivers/scsi/lpfc triggers sparse warnings
Correct the code generating the following errors:
- Incompatible address space assignment without proper conversion.
- Deference of usespace and per-cpu pointers.
Link: https://lore.kernel.org/r/20200501214310.91713-8-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dick Kennedy [Fri, 1 May 2020 21:43:07 +0000 (14:43 -0700)]
scsi: lpfc: Remove unnecessary lockdep_assert_held calls
In an audit of lockdep calls in the driver, there are multiple lockdep
checks in successive calling layers. E.g. a routine checks, and then calls
a lower routine that also checks, and so on. Calling sequences result in
many redundant checks.
Refine the code to remove lower-level lockdep checks. Update comments on
the lock, correcting a few places where lock object in comment was
incorrect.
Link: https://lore.kernel.org/r/20200501214310.91713-7-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dick Kennedy [Fri, 1 May 2020 21:43:06 +0000 (14:43 -0700)]
scsi: lpfc: Change default queue allocation for reduced memory consumption
By default, the driver attempts to allocate a hdwq per logical cpu in order
to provide good cpu affinity. Some systems have extremely high cpu counts
and this can significantly raise memory consumption.
In testing on x86 platforms (non-AMD) it is found that sharing of a hdwq by
a physical cpu and its HT cpu can occur with little performance
degredation. By sharing, the hdwq count can be halved, significantly
reducing the memory overhead.
Change the default behavior of the driver on non-AMD x86 platforms to
share a hdwq by the cpu and its HT cpu.
Link: https://lore.kernel.org/r/20200501214310.91713-6-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dick Kennedy [Fri, 1 May 2020 21:43:05 +0000 (14:43 -0700)]
scsi: lpfc: Fix negation of else clause in lpfc_prep_node_fc4type
Implementation of a previous patch added a condition to an if check that
always end up with the if test being true. Execution of the else clause was
inadvertently negated. The additional condition check was incorrect and
unnecessary after the other modifications had been done in that patch.
Remove the check from the if series.
Link: https://lore.kernel.org/r/20200501214310.91713-5-jsmart2021@gmail.com
Fixes:
b95b21193c85 ("scsi: lpfc: Fix loss of remote port after devloss due to lack of RPIs")
Cc: <stable@vger.kernel.org> # v5.4+
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dick Kennedy [Fri, 1 May 2020 21:43:04 +0000 (14:43 -0700)]
scsi: lpfc: Remove re-binding of nvme rport during registration
The lldd rebinds the ndlp with rport during a nvme rport registration (via
nvme_fc_register_remoteport). If rport & ndlp pointers are same as the
previous one, the lldd will re-use the ndlp and rport association without
re-initialization. This assumption is incorrect. The lldd should be
ignorant of whether the returned rport pointer is new or not, and should
always assume it is new.
Remove the re-binding code, always assumes that rport pointer received from
transport is a new pointer.
Link: https://lore.kernel.org/r/20200501214310.91713-4-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dick Kennedy [Fri, 1 May 2020 21:43:03 +0000 (14:43 -0700)]
scsi: lpfc: Maintain atomic consistency of queue_claimed flag
A previous change introduced the atomic use of queue_claimed flag for eq's
and cq's. The code works fine, but the clearing of the queue_claimed flag
is not atomic.
Change queue_claimed = 0 into xchg(&queue_claimed, 0) to be consistent for
change under atomicity.
Link: https://lore.kernel.org/r/20200501214310.91713-3-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bodo Stroesser [Mon, 27 Apr 2020 15:08:23 +0000 (17:08 +0200)]
scsi: target: tcmu: Make pgr_support and alua_support attributes writable
Currently in tcmu reservation commands are handled by core's pr
implementation (default) or completely rejected (emulate_pr set to 0). We
additionally want to be able to do full reservation handling in
userspace. Therefore we need a way to set TRANSPORT_FLAG_PASSTHROUGH_PGR.
The inverted flag is displayed by attribute pgr_support. Since we moved
the flag from transport/backend to se_device in the previous commit, we now
can make it changeable per device by allowing to write the attribute. The
new field transport_flags_changeable in transport/backend is used to reject
writing if not allowed for a backend.
Regarding ALUA we also want to be able to passthrough commands to userspace
in tcmu. Therefore we need TRANSPORT_FLAG_PASSTHROUGH_ALUA to be
changeable, because by setting it we can switch off all ALUA checks in
core. So we also set TRANSPORT_FLAG_PASSTHROUGH_ALUA in tcmu's
transport_flags_changeable.
Of course, ALUA and reservation handling in userspace will work only, if
session/nexus information is sent to userspace along with every
command. This will be object of a patch series announced by Mike Christie.
Link: https://lore.kernel.org/r/20200427150823.15350-5-bstroesser@ts.fujitsu.com
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>