Xiaofei Tan [Mon, 21 May 2018 10:09:21 +0000 (18:09 +0800)]
scsi: hisi_sas: Include TMF elements in struct hisi_sas_slot
In future scenarios we will want to use the TMF struct for more task types
than SSP.
As such, we can add struct hisi_sas_tmf_task directly into struct
hisi_sas_slot, and this will mean we can remove the TMF parameters from the
task prep functions.
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiaofei Tan [Mon, 21 May 2018 10:09:20 +0000 (18:09 +0800)]
scsi: hisi_sas: Try wait commands before before controller reset
We may reset the controller in many scenarios, such as SCSI EH and HW
errors. There should be no IO which returns from target when SCSI EH is
active. But for other scenarios, there may be. It is not necessary to make
such IOs fail.
This patch adds an function of trying to wait for any commands, or IO, to
complete before host reset. If no more CQ returned from host controller in
100ms, we assume no more IO can return, and then stop waiting. We wait 5s
at most.
The HW has a register CQE_SEND_CNT to indicate the total number of CQs that
has been reported to driver. We can use this register and it is reliable to
resd this register in such scenarios that require host reset.
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiaofei Tan [Mon, 21 May 2018 10:09:19 +0000 (18:09 +0800)]
scsi: hisi_sas: Init disks after controller reset
After the controller is reset, it is possible that the disks attached still
have outstanding IO to complete.
Thus, when the PHYs come back up after controller reset, it is possible
that these IOs complete at some unknown point later.
We want to ensure that all IOs are complete after the controller reset so
that all associated IPTT and other resources can be recycled safely.
To achieve this, re-init the disks by TMF or softreset (in case of ATA
devices).
If the init fails - maybe because the device was removed or link has not
come up - then do not release the device resources, but rather rely on SCSI
EH to handle the timeout for these resources later on.
This patch also does some cleanup to hisi_sas_init_disk(), including
removing superfluous cases in the switch statement.
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Mon, 21 May 2018 10:09:18 +0000 (18:09 +0800)]
scsi: hisi_sas: Create a scsi_host_template per HW module
When a SCSI host is registered, the SCSI mid-layer takes a reference to a
module in Scsi_host.hostt.module. In doing this, we are prevented from
removing the driver module for the host in dangerous scenario, like when a
disk is mounted.
Currently there is only one scsi_host_template (sht) for all HW versions,
and this is the main.c module. So this means that we can possibly remove
the HW module in this dangerous scenario, as SCSI mid-layer is only
referencing the main.c module.
To fix this, create a sht per module, referencing that same module to
create the Scsi host.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Mon, 21 May 2018 10:09:17 +0000 (18:09 +0800)]
scsi: hisi_sas: Reset disks when discovered
When a disk is discovered, it may be in an error state, or there may be
residual commands remaining in the disk.
To ensure any disk is in good state after discovery, reset via TMF (for SAS
disk) or softreset (for a SATA disk).
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiaofei Tan [Mon, 21 May 2018 10:09:16 +0000 (18:09 +0800)]
scsi: hisi_sas: Add LED feature for v3 hw
This patch implements LED feature of directly attached disk for v3 hw.
In fact, this hw has created an SGPIO component for LED feature, and we can
control LEDs just by internal registers.
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Mon, 21 May 2018 10:09:15 +0000 (18:09 +0800)]
scsi: hisi_sas: Change common allocation mode of device id
To reduce possibility of hitting unknown SoC bugs and aid debugging and
test, change allocation mode of device id from last used device id instead
of lowest available index.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Mon, 21 May 2018 10:09:14 +0000 (18:09 +0800)]
scsi: hisi_sas: change slot index allocation mode
Currently we find the lowest available empty bit in the IPTT bitmap to
allocate the IPTT for a command.
To reduce possibility of hitting unknown SoC bugs and also aid in the
debugging of those same bugs, change the allocation mode.
The next allocation method is to use the next free slot adjacent to the
most recently allocated slot, in a round-robin fashion.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
John Garry [Mon, 21 May 2018 10:09:13 +0000 (18:09 +0800)]
scsi: hisi_sas: Introduce hisi_sas_phy_set_linkrate()
There is much common code and functionality between the HW versions to set
the PHY linkrate.
As such, this patch factors out the common code into a generic function
hisi_sas_phy_set_linkrate().
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Wei Yongjun [Sat, 26 May 2018 09:34:22 +0000 (09:34 +0000)]
scsi: hisi_sas: fix a typo in hisi_sas_task_prep()
Fix a typo in hisi_sas_task_prep().
Fixes:
7eee4b921822 ("scsi: hisi_sas: relocate smp sg map")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Colin Ian King [Sat, 26 May 2018 15:02:29 +0000 (16:02 +0100)]
scsi: target: fix spelling mistake "Uknown" -> "Unknown"
Trivial fix to spelling mistake in pr_err message text.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Colin Ian King [Sat, 26 May 2018 14:42:18 +0000 (15:42 +0100)]
scsi: pm80xx: fix spelling mistake "UNSORPORTED" -> "SUPPORTED"
Trivial fix to spelling mistake in pm8001_printk message text; also I
believe NOT_UNSUPPORTED should probably be NOT_SUPPORTED. Also fix the
indent of the pm8001_printk statement.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Douglas Gilbert [Fri, 18 May 2018 23:25:47 +0000 (19:25 -0400)]
scsi: core: sanitize++ in progress
Commit
505aa4b6a883 ("scsi: sd: Defer spinning up drive while SANITIZE is
in progress") may not be sufficient, especially if the SCSI SANITIZE
command is sent via the bsg or sg pass-throughs, since they don't use the
sd driver.
Add "Sanitize in progress" plus some other recent "... in progress"
additional sense codes into the scsi mid-level so they are treated in a
similar fashion to "Format in progress".
[mkp: checkpatch]
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Colin Ian King [Thu, 17 May 2018 07:57:38 +0000 (08:57 +0100)]
scsi: snic: fix a couple of spelling mistakes: "COMPLETE"
Trivial fix to spelling mistakes/typos:
"SNIC_IOREQ_ABTS_COMPELTE" -> "SNIC_IOREQ_ABTS_COMPLETE"
"SNIC_IOREQ_LR_COMPELTE" -> "SNIC_IOREQ_LR_COMPLETE"
"SNIC_IOREQ_CMD_COMPELTE" -> "SNIC_IOREQ_CMD_COMPLETE"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Lee Duncan [Wed, 16 May 2018 01:25:24 +0000 (18:25 -0700)]
scsi: target: transport should handle st FM/EOM/ILI reads
When a tape drive is exported via LIO using the pscsi module, a read
that requests more bytes per block than the tape can supply returns an
empty buffer. This is because the pscsi pass-through target module sees
the "ILI" illegal length bit set and thinks there is no reason to return
the data.
This is a long-standing transport issue, since it assumes that no data
need be returned under a check condition, which isn't always the case
for tape.
Add in a check for tape reads with the ILI, EOM, or FM bits set, with a
sense code of NO_SENSE, treating such cases as if the read
succeeded. The layered tape driver then "does the right thing" when it
gets such a response.
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Lee Duncan <lduncan@suse.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Christophe Jaillet [Thu, 10 May 2018 11:45:58 +0000 (13:45 +0200)]
scsi: qlogicpti: Fix an error handling path in 'qpti_sbus_probe()'
The 'free_irq()' call is not at the right place in the error handling
path. The changed order has been introduced in commit
3d4253d9afab
("[SCSI] qlogicpti: Convert to new SBUS device framework.")
Fixes:
3d4253d9afab ("[SCSI] qlogicpti: Convert to new SBUS device framework.")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Vijay Viswanath [Thu, 3 May 2018 11:07:22 +0000 (16:37 +0530)]
scsi: ufs: Add clock ungating to a separate workqueue
UFS driver can receive a request during memory reclaim by kswapd. So
when ufs driver puts the ungate work in queue, and if there are no idle
workers, kthreadd is invoked to create a new kworker. Since kswapd task
holds a mutex which kthreadd also needs, this can cause a deadlock
situation. So ungate work must be done in a separate work queue with
WQ_MEM_RECLAIM flag enabled. Such a workqueue will have a rescue thread
which will be called when the above deadlock condition is possible.
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Venkat Gopalakrishnan [Thu, 3 May 2018 11:07:20 +0000 (16:37 +0530)]
scsi: ufs: make sure all interrupts are processed
As multiple requests are submitted to the ufs host controller in
parallel there could be instances where the command completion interrupt
arrives later for a request that is already processed earlier as the
corresponding doorbell was cleared when handling the previous
interrupt. Read the interrupt status in a loop after processing the
received interrupt to catch such interrupts and handle it.
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Subhash Jadavani [Thu, 3 May 2018 11:07:19 +0000 (16:37 +0530)]
scsi: ufs: ufs-qcom: remove broken hci version quirk
UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION is only applicable for QCOM UFS host
controller version 2.x.y and this has been fixed from version 3.x.y
onwards, hence this change removes this quirk for version 3.x.y onwards.
[mkp: applied by hand]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Subhash Jadavani [Thu, 3 May 2018 11:07:18 +0000 (16:37 +0530)]
scsi: ufs: add reference counting for scsi block requests
Currently we call the scsi_block_requests()/scsi_unblock_requests()
whenever we want to block/unblock scsi requests but as there is no
reference counting, nesting of these calls could leave us in undesired
state sometime. Consider following call flow sequence:
1. func1() calls scsi_block_requests() but calls func2() before
calling scsi_unblock_requests()
2. func2() calls scsi_block_requests()
3. func2() calls scsi_unblock_requests()
4. func1() calls scsi_unblock_requests()
As there is no reference counting, we will have scsi requests unblocked
after #3 instead of it to be unblocked only after #4. Though we may not
have failures seen with this, we might run into some failures in future.
Better solution would be to fix this by adding reference counting.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Subhash Jadavani [Thu, 3 May 2018 11:07:17 +0000 (16:37 +0530)]
scsi: ufs: ufshcd: fix possible unclocked register access
Vendor specific setup_clocks ops may depend on clocks managed by ufshcd
driver so if the vendor specific setup_clocks callback is called when
the required clocks are turned off, it results into unclocked register
access.
This change make sure that required clocks are enabled before vendor
specific setup_clocks callback is called.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Maya Erez [Thu, 3 May 2018 11:07:16 +0000 (16:37 +0530)]
scsi: ufs: fix exception event handling
The device can set the exception event bit in one of the response UPIU,
for example to notify the need for urgent BKOPs operation. In such a
case, the host driver calls ufshcd_exception_event_handler to handle
this notification. When trying to check the exception event status (for
finding the cause for the exception event), the device may be busy with
additional SCSI commands handling and may not respond within the 100ms
timeout.
To prevent that, we need to block SCSI commands during handling of
exception events and allow retransmissions of the query requests, in
case of timeout.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Kees Cook [Wed, 2 May 2018 22:21:38 +0000 (15:21 -0700)]
scsi: dpt_i2o: Remove VLA usage
On the quest to remove all VLAs from the kernel[1] this moves the
sg_list variable off the stack, as already done for other allocated
buffers in adpt_i2o_passthru(). Additionally consolidates the error path
for kfree().
[1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bjorn Andersson [Fri, 18 May 2018 06:26:37 +0000 (23:26 -0700)]
scsi: ufs: Use freq table with devfreq
devfreq requires that the client operates on actual frequencies, not only 0
and UMAX_INT and as such UFS brok with the introduction of
f1d981eaecf8 ("PM
/ devfreq: Use the available min/max frequency").
This patch registers the frequencies of the first clock with devfreq and use
these to determine if we're trying to step up or down.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> [for devfreq & OPP part]
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bjorn Andersson [Fri, 18 May 2018 06:26:36 +0000 (23:26 -0700)]
scsi: ufs: Extract devfreq registration
Failing to register with devfreq leaves hba->devfreq assigned, which causes
the error path to dereference the ERR_PTR(). Rather than bolting on more
conditionals, move the call of devm_devfreq_add_device() into it's own
function and only update hba->devfreq once it's successfully registered.
The subsequent patch builds upon this to make UFS actually work again, as
it's been broken since
f1d981eaecf8 ("PM / devfreq: Use the available
min/max frequency")
Also switch to use DEVFREQ_GOV_SIMPLE_ONDEMAND constant.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Michael Kelley [Thu, 17 May 2018 21:07:40 +0000 (14:07 -0700)]
scsi: storvsc: Avoid allocating memory for temp cpumasks
Current code allocates 240 Kbytes (in typical configs) for each synthetic
SCSI controller to use as temp cpumask variables. Recode to avoid needing
the temp cpumask variables and remove the memory allocation.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Acked-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Jens Remus [Thu, 17 May 2018 17:15:07 +0000 (19:15 +0200)]
scsi: zfcp: enhance comments on fc_link_speed and supported_speed
The comment on fsf_qtcb_bottom_port.supported_speed did read as if the field
can only assume one of two possible values (i.e. 0x1 for 1 GBit/s or 0x2 for
2 GBit/s). This is not true for two reasons: first it is a flag field and
can thus assume any combination and second there are meanwhile more speeds.
Clarify comment on fsf_qtcb_bottom_port.supported_speed and add a comment to
fsf_qtcb_bottom_config.fc_link_speed.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Acked-by: Benjamin Block <bblock@linux.ibm.com>
Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Jens Remus [Thu, 17 May 2018 17:15:06 +0000 (19:15 +0200)]
scsi: zfcp: add port speed capabilities
Add port speed capabilities as defined in FC-LS RPSC ELS that have a
counterpart FC_PORTSPEED_* defined in scsi/scsi_transport_fc.h.
Suggested-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Acked-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Jens Remus [Thu, 17 May 2018 17:15:05 +0000 (19:15 +0200)]
scsi: zfcp: assert that the ERP lock is held when tracing a recovery trigger
Otherwise iterating with list_for_each() over the adapter->erp_ready_head
and adapter->erp_running_head lists can lead to an infinite loop. See commit
"zfcp: fix infinite iteration on erp_ready_head list".
The run-time check is only performed for debug kernels which have the kernel
lock validator enabled. Following is an example of the warning that is
reported, if the ERP lock is not held when calling zfcp_dbf_rec_trig():
WARNING: CPU: 0 PID: 604 at drivers/s390/scsi/zfcp_dbf.c:288 zfcp_dbf_rec_trig+0x172/0x188
Modules linked in: ...
CPU: 0 PID: 604 Comm: kworker/u128:3 Not tainted 4.16.0-... #1
Hardware name: IBM 2964 N96 702 (z/VM 6.4.0)
Workqueue: zfcp_q_0.0.1906 zfcp_scsi_rport_work
Krnl PSW :
00000000330fdbf9 00000000367e9728 (zfcp_dbf_rec_trig+0x172/0x188)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
Krnl GPRS:
00000000c57a5d99 3288200000000000 0000000000000000 000000006cc82740
00000000009d09d6 0000000000000000 00000000000000ff 0000000000000000
0000000000000000 0000000000e1b5fe 000000006de01d38 0000000076130958
000000006cc82548 000000006de01a98 00000000009d09d6 000000006a6d3c80
Krnl Code:
00000000009d0ad2:
eb7ff0b80004 lmg %r7,%r15,184(%r15)
00000000009d0ad8:
c0f4000d7dd0 brcl 15,b80678
#
00000000009d0ade:
a7f40001 brc 15,9d0ae0
>
00000000009d0ae2:
a7f4ff7d brc 15,9d09dc
00000000009d0ae6:
e340f0f00004 lg %r4,240(%r15)
00000000009d0aec:
eb7ff0b80004 lmg %r7,%r15,184(%r15)
00000000009d0af2: 07f4 bcr 15,%r4
00000000009d0af4: 0707 bcr 0,%r7
Call Trace:
([<
00000000009d09d6>] zfcp_dbf_rec_trig+0x66/0x188)
[<
00000000009dd740>] zfcp_scsi_rport_work+0x98/0x190
[<
0000000000169b34>] process_one_work+0x3d4/0x6f8
[<
000000000016a08a>] worker_thread+0x232/0x418
[<
000000000017219e>] kthread+0x166/0x178
[<
0000000000b815ea>] kernel_thread_starter+0x6/0xc
[<
0000000000b815e4>] kernel_thread_starter+0x0/0xc
2 locks held by kworker/u128:3/604:
#0: ((wq_completion)name){+.+.}, at: [<
0000000082af1024>] process_one_work+0x1dc/0x6f8
#1: ((work_completion)(&port->rport_work)){+.+.}, at: [<
0000000082af1024>] process_one_work+0x1dc/0x6f8
Last Breaking-Event-Address:
[<
00000000009d0ade>] zfcp_dbf_rec_trig+0x16e/0x188
---[ end trace
b2f4020572e2c124 ]---
Suggested-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:15:04 +0000 (19:15 +0200)]
scsi: zfcp: cleanup indentation for posting FC events
I just happened to see the function header indentation of
zfcp_fc_enqueue_event() and I picked some more from checkpatch:
$ checkpatch.pl --strict -f drivers/s390/scsi/zfcp_fc.c
...
CHECK: Alignment should match open parenthesis
#113: FILE: drivers/s390/scsi/zfcp_fc.c:113:
+ fc_host_post_event(adapter->scsi_host, fc_get_event_number(),
+ event->code, event->data);
CHECK: Blank lines aren't necessary before a close brace '}'
#118: FILE: drivers/s390/scsi/zfcp_fc.c:118:
+
+}
...
The change complements v2.6.36 commit
2d1e547f7523 ("[SCSI] zfcp: Post
events through FC transport class").
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:15:03 +0000 (19:15 +0200)]
scsi: zfcp: support SCSI_ADAPTER_RESET via scsi_host sysfs attribute host_reset
Make use of feature introduced with v3.2 commit
294436914454 ("[SCSI] scsi:
Added support for adapter and firmware reset"). The common code interface
was introduced for commit
95d31262b3c1 ("[SCSI] qla4xxx: Added support for
adapter and firmware reset").
$ echo adapter > /sys/class/scsi_host/host<N>/host_reset
Example trace record formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : REC
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1 ZFCP_DBF_REC_TRIG
Tag : scshr_y SCSI sysfs host_reset yes
LUN : 0xffffffffffffffff none (invalid)
WWPN : 0x0000000000000000 none (invalid)
D_ID : 0x00000000 none (invalid)
Adapter status : 0x4500050b
Port status : 0x00000000 none (invalid)
LUN status : 0x00000000 none (invalid)
Ready count : 0x00000001
Running count : 0x00000000
ERP want : 0x04 ZFCP_ERP_ACTION_REOPEN_ADAPTER
ERP need : 0x04 ZFCP_ERP_ACTION_REOPEN_ADAPTER
This is the common code equivalent to the zfcp-specific
&dev_attr_adapter_failed.attr in zfcp_sysfs_adapter_attrs.attrs[]:
$ echo 0 > /sys/bus/ccw/drivers/zfcp/<devbusid>/failed
The unsupported case returns EOPNOTSUPP:
$ echo firmware > /sys/class/scsi_host/host<N>/host_reset
-bash: echo: write error: Operation not supported
Example trace record formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : SCSI
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1
Tag : scshr_n SCSI sysfs host_reset no
Request ID : 0x0000000000000000 none (invalid)
SCSI ID : 0xffffffff none (invalid)
SCSI LUN : 0xffffffff none (invalid)
SCSI LUN high : 0xffffffff none (invalid)
SCSI result : 0xffffffa1 -EOPNOTSUPP==-95
SCSI retries : 0xff none (invalid)
SCSI allowed : 0xff none (invalid)
SCSI scribble : 0xffffffffffffffff none (invalid)
SCSI opcode :
ffffffff ffffffff ffffffff ffffffff none (invalid)
FCP rsp inf cod: 0xff none (invalid)
FCP rsp IU :
00000000 00000000 00000000 00000000 none (invalid)
00000000 00000000
For any other invalid value, common code returns EINVAL without invoking
our callback:
$ echo foo > /sys/class/scsi_host/host<N>/host_reset
-bash: echo: write error: Invalid argument
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:15:02 +0000 (19:15 +0200)]
scsi: zfcp: explicitly support initiator in scsi_host_template
While the default did already correctly print "Initiator" let's make it
explicit and convert zfcp to the feature.
$ cat /sys/class/scsi_host/host0/supported_mode
Initiator
$ cat /sys/class/scsi_host/host0/active_mode
Initiator
The default worked, because not setting the field has it initialized to zero
== MODE_UNKNOWN. scsi_host_alloc() sets shost->active_mode = MODE_INITIATOR
in this case. The sysfs accessor function show_shost_supported_mode()
assumes MODE_INITIATOR in this case. This default behavior was introduced
with v2.6.24 commit
7a39ac3f25be ("[SCSI] make supported_mode default to
initiator."). The feature flag was introduced with v2.6.24 commit
5dc2b89e1242 ("[SCSI] add supported_mode and active_mode attributes to the
host"). So there was no release where zfcp would have shown "unknown".
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:15:01 +0000 (19:15 +0200)]
scsi: zfcp: remove unused return values of ERP trigger functions
Since v2.6.27 commit
553448f6c483 ("[SCSI] zfcp: Message cleanup"), none of
the callers has been interested any more. Values were not returned
consistently in all ERP trigger functions.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:15:00 +0000 (19:15 +0200)]
scsi: zfcp: zfcp_erp_action_exists() does only check for running
Simplify its signature to return boolean and rename it to
zfcp_erp_action_is_running() to indicate its actual unmodified semantics.
It has always been used like this since v2.6.0 history commit
ea127f975424
("[PATCH] s390 (7/7): zfcp host adapter.").
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:59 +0000 (19:14 +0200)]
scsi: zfcp: remove unused ERP enum values
All constant defines were introduced with v2.6.0 history commit
ea127f975424
("[PATCH] s390 (7/7): zfcp host adapter.") and refactored into enums with
commit
287ac01acf22 ("[SCSI] zfcp: Cleanup code in zfcp_erp.c").
ZFCP_STATUS_ERP_DISMISSING and ZFCP_ERP_STEP_FSF_XCONFIG were never used.
v2.6.27 commit
287ac01acf22 ("[SCSI] zfcp: Cleanup code in zfcp_erp.c")
removed the use of ZFCP_ERP_ACTION_READY on refactoring
zfcp_erp_action_exists() to now only check adapter->erp_running_head but no
longer adapter->erp_ready_head. The same commit could have changed the
function return type from int to "enum zfcp_erp_act_state".
ZFCP_ERP_ACTION_READY was never used outside of zfcp_erp_action_exists().
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:58 +0000 (19:14 +0200)]
scsi: zfcp: consistently use function name space prefix
I've been mixing up
zfcp_task_mgmt_function() [SCSI] and
zfcp_fsf_fcp_task_mgmt() [FSF]
so often lately that I wanted to fix this.
SCSI changes complement v2.6.27 commit
f76af7d7e363 ("[SCSI] zfcp: Cleanup
of code in zfcp_scsi.c").
While at it, also fixup the other inconsistencies elsewhere.
ERP changes complement v2.6.27 commit
287ac01acf22 ("[SCSI] zfcp: Cleanup
code in zfcp_erp.c") which introduced status_change_set().
FC changes complement v2.6.32 commit
6f53a2d2ecae ("[SCSI] zfcp: Apply
common naming conventions to zfcp_fc"). by renaming a leftover introduced
with v2.6.27 commit
cc8c282963bd ("[SCSI] zfcp: Automatically attach remote
ports").
FSF changes fixup v2.6.32 commit
a4623c467ff7 ("[SCSI] zfcp: Improve request
allocation through mempools"). which replaced zfcp_fsf_alloc_qtcb()
introduced with v2.6.27 commit
c41f8cbddd4e ("[SCSI] zfcp: zfcp_fsf
cleanup.").
SCSI fc_host statistics were introduced with v2.6.16 commit
f6cd94b126aa
("[SCSI] zfcp: transport class adaptations").
SCSI fc_host port_state was introduced with v2.6.27 commit
85a82392fe6f
("[SCSI] zfcp: Add port_state attribute to sysfs").
SCSI rport setter for dev_loss_tmo was introduced with v2.6.18 commit
338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target
port is unavailable").
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:57 +0000 (19:14 +0200)]
scsi: zfcp: workqueue: set description for port work items with their WWPN as context
As a prerequisite, complement commit
3d1cb2059d93 ("workqueue: include
workqueue info when printing debug dump of a worker task") to be usable with
kernel modules by exporting the symbol set_worker_desc(). Current built-in
user was introduced with commit
ef3b101925f2 ("writeback: set worker desc to
identify writeback workers in task dumps").
Can help distinguishing work items which do not have adapter scope.
Description is printed out with task dump for debugging on WARN, BUG, panic,
or magic-sysrq [show-task-states(t)].
Example:
$ echo 0 >| /sys/bus/ccw/drivers/zfcp/0.0.1880/0x50050763031bd327/failed &
$ echo 't' >| /proc/sysrq-trigger
$ dmesg
sysrq: SysRq : Show State
task PC stack pid father
...
zfcp_q_0.0.1880 S14640 2165 2 0x02000000
Call Trace:
([<
00000000009df464>] __schedule+0xbf4/0xc78)
[<
00000000009df57c>] schedule+0x94/0xc0
[<
0000000000168654>] rescuer_thread+0x33c/0x3a0
[<
000000000016f8be>] kthread+0x166/0x178
[<
00000000009e71f2>] kernel_thread_starter+0x6/0xc
[<
00000000009e71ec>] kernel_thread_starter+0x0/0xc
no locks held by zfcp_q_0.0.1880/2165.
...
kworker/u512:2 D11280 2193 2 0x02000000
Workqueue: zfcp_q_0.0.1880 zfcp_scsi_rport_work [zfcp] (zrpd-
50050763031bd327)
^^^^^^^^^^^^^^^^^^^^^
Call Trace:
([<
00000000009df464>] __schedule+0xbf4/0xc78)
[<
00000000009df57c>] schedule+0x94/0xc0
[<
00000000009e50c0>] schedule_timeout+0x488/0x4d0
[<
00000000001e425c>] msleep+0x5c/0x78 >>test code only<<
[<
000003ff8008a21e>] zfcp_scsi_rport_work+0xbe/0x100 [zfcp]
[<
0000000000167154>] process_one_work+0x3b4/0x718
[<
000000000016771c>] worker_thread+0x264/0x408
[<
000000000016f8be>] kthread+0x166/0x178
[<
00000000009e71f2>] kernel_thread_starter+0x6/0xc
[<
00000000009e71ec>] kernel_thread_starter+0x0/0xc
2 locks held by kworker/u512:2/2193:
#0: (name){++++.+}, at: [<
0000000000166f4e>] process_one_work+0x1ae/0x718
#1: ((&(&port->rport_work)->work)){+.+.+.}, at: [<
0000000000166f4e>] process_one_work+0x1ae/0x718
...
=============================================
Showing busy workqueues and worker pools:
workqueue zfcp_q_0.0.1880: flags=0x2000a
pwq 512: cpus=0-255 flags=0x4 nice=0 active=1/1
in-flight: 2193:zfcp_scsi_rport_work [zfcp]
pool 512: cpus=0-255 flags=0x4 nice=0 hung=0s workers=4 idle: 5 2354 2311
Work items with adapter scope are already identified by the workqueue name
"zfcp_q_<devbusid>" and the work item function name.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:56 +0000 (19:14 +0200)]
scsi: zfcp: decouple our scsi_eh callbacks from scsi_cmnd
Note: zfcp_scsi_eh_host_reset_handler() will be converted in a later patch.
zfcp_scsi_eh_device_reset_handler() now only depends on scsi_device.
zfcp_scsi_eh_target_reset_handler() now only depends on scsi_target.
All derive other objects from these intended callback arguments.
zfcp_scsi_eh_target_reset_handler() is special: The FCP channel requires a
valid LUN handle so we try to find ourselves a stand-in scsi_device as
suggested by Hannes Reinecke. If it cannot find a stand-in scsi device,
trace a record like the following (formatted with zfcpdbf from s390-tools):
Timestamp : ...
Area : SCSI
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1
Tag : tr_nosd target reset, no SCSI device
Request ID : 0x0000000000000000 none (invalid)
SCSI ID : 0x00000000 SCSI ID/target denoting scope
SCSI LUN : 0xffffffff none (invalid)
SCSI LUN high : 0xffffffff none (invalid)
SCSI result : 0x00002003 field re-used for midlayer value: FAILED
SCSI retries : 0xff none (invalid)
SCSI allowed : 0xff none (invalid)
SCSI scribble : 0xffffffffffffffff none (invalid)
SCSI opcode :
ffffffff ffffffff ffffffff ffffffff none (invalid)
FCP rsp inf cod: 0xff none (invalid)
FCP rsp IU :
00000000 00000000 00000000 00000000 none (invalid)
00000000 00000000
Actually change the signature of zfcp_task_mgmt_function() used by
zfcp_scsi_eh_device_reset_handler() & zfcp_scsi_eh_target_reset_handler().
Since it was prepared in a previous patch, we only need to delete a local
auto variable which is now the intended argument.
Suggested-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:55 +0000 (19:14 +0200)]
scsi: zfcp: decouple TMFs from scsi_cmnd by using fc_block_rport
Intentionally retrieve the rport by walking SCSI common code objects
rather than zfcp_sdev->port->rport.
The latter is used for pairing the calls to fc_remote_port_add() and
fc_remote_port_delete(). [see v2.6.31 commit
379d6bf6573e ("[SCSI] zfcp:
Add port only once to FC transport class")]
zfcp_scsi_rport_register() sets zfcp_port.rport to what
fc_remote_port_add() returned.
zfcp_scsi_rport_block() sets zfcp_port.rport = NULL after having called
fc_remote_port_delete().
Hence, while an rport is blocked (or in any subsequent state due to
scsi_transport_fc timeouts such as fast_io_fail_tmo or dev_loss_tmo),
zfcp_port.rport is NULL and cannot serve as argument to fc_block_rport().
During zfcp recovery, a just recovered zfcp_port can have the UNBLOCKED
status flag, but an async rport unblocking has only started via
zfcp_scsi_schedule_rport_register() in zfcp_erp_try_rport_unblock()
[see v4.10 commit
6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with
LUN recovery")] in zfcp_erp_action_cleanup(). Now zfcp_erp_wait() can
return. This would be sufficient to successfully send a TMF.
But the rport can still be blocked and zfcp_port.rport can still be NULL
until zfcp_port.rport_work was scheduled and has actually called
fc_remote_port_add() and assigned its return value to zfcp_port.rport.
We need an unblocked rport for a successful scsi_eh TUR.
Similarly, for a zfcp_port which has just lost its UNBLOCKED status flag,
the return of zfcp_erp_wait() can race with zfcp_port.rport_work queued
by zfcp_scsi_schedule_rport_block(). Therefore we cannot reliably access
zfcp_port.rport. However, we'd like to get fc_rport_block()'s opinion on
when fast_io_fail_tmo triggered. While we might use
flush_work(&port->rport_work) to sync with the work item, we can simply use
the other way to get an rport pointer.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:54 +0000 (19:14 +0200)]
scsi: zfcp: decouple SCSI setup of TMF from scsi_cmnd
Actually change the signature of zfcp_fsf_fcp_task_mgmt().
Since it was prepared in the previous patch, we only need to delete
a local auto variable which is now the intended argument.
Prepare zfcp_fsf_fcp_task_mgmt's caller zfcp_task_mgmt_function()
to have its function body only depend on a scsi_device and derived objects.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:53 +0000 (19:14 +0200)]
scsi: zfcp: decouple FSF request setup of TMF from scsi_cmnd
In zfcp_fsf_fcp_task_mgmt() resolve the still old argument scsi_cmnd into
scsi_device very early and only depend on scsi_device and derived objects in
the function body.
This prepares to later change the function signature replacing the scsi_cmnd
argument with scsi_device.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:52 +0000 (19:14 +0200)]
scsi: zfcp: split FCP_CMND IU setup between SCSI I/O and TMF again
This reverts commit
2443c8b23aea ("[SCSI] zfcp: Merge FCP task management
setup with regular FCP command setup"), because this introduced a
dependency on the unsuitable SCSI command for scsi_eh / TMF.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:51 +0000 (19:14 +0200)]
scsi: zfcp: decouple TMF response handler from scsi_cmnd
Originally, I planned for TMF handling to have different context data in
fsf_req->data depending on the TMF scope in fcp_cmnd->fc_tm_flags:
* scsi_device if FCP_TMF_LUN_RESET,
* zfcp_port if FCP_TMF_TGT_RESET.
However, the FCP channel requires a valid LUN handle so we now use
scsi_device as context data with any TMF for the time being.
Regular SCSI I/O FCP requests continue using scsi_cmnd as req->data.
Hence, the callers of zfcp_fsf_fcp_handler_common() must resolve req->data
and pass scsi_device as common context. While at it, remove the detour
zfcp_sdev->port->adapter and use the more direct req->adapter as elsewhere
in this function already.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:50 +0000 (19:14 +0200)]
scsi: zfcp: decouple SCSI traces for scsi_eh / TMF from scsi_cmnd
The SCSI command pointer passed to scsi_eh callbacks is just one arbitrary
command of potentially many that are in the eh queue to be processed. The
command is only used to indirectly pass the TMF scope in terms of SCSI
ID/target and SCSI LUN for LUN reset.
Hence, zfcp had filled in SCSI trace record fields which do not really
belong to the TMF. This was confusing.
Therefore, refactor the TMF tracing to work without SCSI command. Since the
FCP channel always requires a valid LUN handle, we use SCSI device as common
context for any TMF (even target reset). To make it even clearer, we set
all bits to 1 for the fields, which do not belong to the TMF, to indicate
that these fields are invalid.
The old zfcp_dbf_scsi() became zfcp_dbf_scsi_common() to now handle both
SCSI commands and TMFs. The old argument scsi_cmnd is now optional and can
be NULL with TMFs. The new argument scsi_device is mandatory to carry
context, as well as SCSI ID/target and SCSI LUN in case of TMFs.
New example trace record formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : SCSI
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1
Tag : [lt]r_....
Request ID : 0x<reqid> ID of FSF FCP request with TM flag
For cases without FSF request: 0x0 for none (invalid)
SCSI ID : 0x<scsi_id> SCSI ID/target denoting scope
SCSI LUN : 0x<scsi_lun> SCSI LUN denoting scope
SCSI LUN high : 0x<scsi_lun_high> SCSI LUN denoting scope
SCSI result : 0xffffffff none (invalid)
SCSI retries : 0xff none (invalid)
SCSI allowed : 0xff none (invalid)
SCSI scribble : 0xffffffffffffffff none (invalid)
SCSI opcode :
ffffffff ffffffff ffffffff ffffffff none (invalid)
FCP rsp inf cod: 0x00 FCP_RSP info code of TMF
FCP rsp IU :
00000000 00000000 00000100 00000000 ext FCP_RSP IU
00000000 00000008 ext FCP_RSP IU
FCP rsp IU len : 32 FCP_RSP IU length
Payload time : ...
FCP rsp IU all :
00000000 00000000 00000100 00000000 full FCP_RSP IU
00000000 00000008 00000000 00000000 full FCP_RSP IU
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:49 +0000 (19:14 +0200)]
scsi: zfcp: fix missing REC trigger trace on enqueue without ERP thread
Example trace record formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : REC
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1 ZFCP_DBF_REC_TRIG
Tag : .......
LUN : 0x...
WWPN : 0x...
D_ID : 0x...
Adapter status : 0x...
Port status : 0x...
LUN status : 0x...
Ready count : 0x...
Running count : 0x...
ERP want : 0x0. ZFCP_ERP_ACTION_REOPEN_...
ERP need : 0xc0 ZFCP_ERP_ACTION_NONE
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.38+
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:48 +0000 (19:14 +0200)]
scsi: zfcp: fix missing REC trigger trace for all objects in ERP_FAILED
That other commit introduced an inconsistency because it would trace on
ERP_FAILED for all callers of port forced reopen triggers (not just
terminate_rport_io), but it would not trace on ERP_FAILED for all callers of
other ERP triggers such as adapter, port regular, LUN.
Therefore, generalize that other commit. zfcp_erp_action_enqueue() already
had two early outs which re-used the one zfcp_dbf_rec_trig() call. All ERP
trigger functions finally run through zfcp_erp_action_enqueue(). So move
the special handling for ZFCP_STATUS_COMMON_ERP_FAILED into
zfcp_erp_action_enqueue() and add another early out with new trace marker
for pseudo ERP need in this case. This removes all early returns from all
ERP trigger functions so we always end up at zfcp_dbf_rec_trig().
Example trace record formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : REC
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1 ZFCP_DBF_REC_TRIG
Tag : .......
LUN : 0x...
WWPN : 0x...
D_ID : 0x...
Adapter status : 0x...
Port status : 0x...
LUN status : 0x...
Ready count : 0x...
Running count : 0x...
ERP want : 0x0. ZFCP_ERP_ACTION_REOPEN_...
ERP need : 0xe0 ZFCP_ERP_ACTION_FAILED
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.38+
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:47 +0000 (19:14 +0200)]
scsi: zfcp: fix missing REC trigger trace on terminate_rport_io for ERP_FAILED
For problem determination we always want to see when we were invoked on the
terminate_rport_io callback whether we perform something or not.
Temporal event sequence of interest with a long fast_io_fail_tmo of 27 sec:
loose remote port
t workqueue
[s] zfcp_q_<dev> IRQ zfcperp<dev>
=== ================== =================== ============================
0 recv RSCN
q p.test_link_work
block rport
start fast_io_fail_tmo
send ADISC ELS
4 recv ADISC fail
block zfcp_port
port forced reopen
send open port
12 recv open port fail
q p.gid_pn_work
zfcp_erp_wakeup
(zfcp_erp_wait would return)
GID_PN fail
Before this point, we got a SCSI trace with tag "sctrpi1" on fast_io_fail,
e.g. with the typical 5 sec setting.
port.status |= ERP_FAILED
If fast_io_fail_tmo triggers after this point, we missed a SCSI trace.
workqueue
fc_dl_<host>
==================
27 fc_timeout_fail_rport_io
fc_terminate_rport_io
zfcp_scsi_terminate_rport_io
zfcp_erp_port_forced_reopen
_zfcp_erp_port_forced_reopen
if (port.status & ERP_FAILED)
return;
Therefore, write a trace before above early return.
Example trace record formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : REC
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1 ZFCP_DBF_REC_TRIG
Tag : sctrpi1 SCSI terminate rport I/O
LUN : 0xffffffffffffffff none (invalid)
WWPN : 0x<wwpn>
D_ID : 0x<n_port_id>
Adapter status : 0x...
Port status : 0x...
LUN status : 0x00000000 none (invalid)
Ready count : 0x...
Running count : 0x...
ERP want : 0x03 ZFCP_ERP_ACTION_REOPEN_PORT_FORCED
ERP need : 0xe0 ZFCP_ERP_ACTION_FAILED
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.38+
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:46 +0000 (19:14 +0200)]
scsi: zfcp: fix missing REC trigger trace on terminate_rport_io early return
get_device() and its internally used kobject_get() only return NULL if they
get passed NULL as argument. zfcp_get_port_by_wwpn() loops over
adapter->port_list so the iteration variable port is always non-NULL.
Struct device is embedded in struct zfcp_port so &port->dev is always
non-NULL. This is the argument to get_device(). However, if we get an
fc_rport in terminate_rport_io() for which we cannot find a match within
zfcp_get_port_by_wwpn(), the latter can return NULL. v2.6.30 commit
70932935b61e ("[SCSI] zfcp: Fix oops when port disappears") introduced an
early return without adding a trace record for this case. Even if we don't
need recovery in this case, for debugging we should still see that our
callback was invoked originally by scsi_transport_fc.
Example trace record formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : REC
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1
Tag : sctrpin SCSI terminate rport I/O, no zfcp port
LUN : 0xffffffffffffffff none (invalid)
WWPN : 0x<wwpn> WWPN
D_ID : 0x<n_port_id> N_Port-ID
Adapter status : 0x...
Port status : 0xffffffff unknown (-1)
LUN status : 0x00000000 none (invalid)
Ready count : 0x...
Running count : 0x...
ERP want : 0x03 ZFCP_ERP_ACTION_REOPEN_PORT_FORCED
ERP need : 0xc0 ZFCP_ERP_ACTION_NONE
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Fixes:
70932935b61e ("[SCSI] zfcp: Fix oops when port disappears")
Cc: <stable@vger.kernel.org> #2.6.38+
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:45 +0000 (19:14 +0200)]
scsi: zfcp: fix misleading REC trigger trace where erp_action setup failed
If a SCSI device is deleted during scsi_eh host reset, we cannot get a
reference to the SCSI device anymore since scsi_device_get returns !=0 by
design. Assuming the recovery of adapter and port(s) was successful,
zfcp_erp_strategy_followup_success() attempts to trigger a LUN reset for the
half-gone SCSI device. Unfortunately, it causes the following confusing
trace record which states that zfcp will do a LUN recovery as "ERP need" is
ZFCP_ERP_ACTION_REOPEN_LUN == 1 and equals "ERP want".
Old example trace record formatted with zfcpdbf from s390-tools:
Tag: : ersfs_3 ERP, trigger, unit reopen, port reopen succeeded
LUN : 0x<FCP_LUN>
WWPN : 0x<WWPN>
D_ID : 0x<N_Port-ID>
Adapter status : 0x5400050b
Port status : 0x54000001
LUN status : 0x40000000 ZFCP_STATUS_COMMON_RUNNING
but not ZFCP_STATUS_COMMON_UNBLOCKED as it
was closed on close part of adapter reopen
ERP want : 0x01
ERP need : 0x01 misleading
However, zfcp_erp_setup_act() returns NULL as it cannot get the reference.
Hence, zfcp_erp_action_enqueue() takes an early goto out and _NO_ recovery
actually happens.
We always do want the recovery trigger trace record even if no erp_action
could be enqueued as in this case. For other cases where we did not enqueue
an erp_action, 'need' has always been zero to indicate this. In order to
indicate above goto out, introduce an eyecatcher "flag" to mark the "ERP
need" as 'not needed' but still keep the information which erp_action type,
that zfcp_erp_required_act() had decided upon, is needed. 0xc_ is chosen to
be visibly different from 0x0_ in "ERP want".
New example trace record formatted with zfcpdbf from s390-tools:
Tag: : ersfs_3 ERP, trigger, unit reopen, port reopen succeeded
LUN : 0x<FCP_LUN>
WWPN : 0x<WWPN>
D_ID : 0x<N_Port-ID>
Adapter status : 0x5400050b
Port status : 0x54000001
LUN status : 0x40000000
ERP want : 0x01
ERP need : 0xc1 would need LUN ERP, but no action set up
^
Before v2.6.38 commit
ae0904f60fab ("[SCSI] zfcp: Redesign of the debug
tracing for recovery actions.") we could detect this case because the
"erp_action" field in the trace was NULL. The rework removed erp_action as
argument and field from the trace.
This patch here is for tracing. A fix to allow LUN recovery in the case at
hand is a topic for a separate patch.
See also commit
fdbd1c5e27da ("[SCSI] zfcp: Allow running unit/LUN shutdown
without acquiring reference") for a similar case and background info.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Fixes:
ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
Cc: <stable@vger.kernel.org> #2.6.38+
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:44 +0000 (19:14 +0200)]
scsi: zfcp: fix missing SCSI trace for retry of abort / scsi_eh TMF
We already have a SCSI trace for the end of abort and scsi_eh TMF. Due to
zfcp_erp_wait() and fc_block_scsi_eh() time can pass between the start of
our eh callback and an actual send/recv of an abort / TMF request. In order
to see the temporal sequence including any abort / TMF send retries, add a
trace before the above two blocking functions. This supports problem
determination with scsi_eh and parallel zfcp ERP.
No need to explicitly trace the beginning of our eh callback, since we
typically can send an abort / TMF and see its HBA response (in the worst
case, it's a pseudo response on dismiss all of adapter recovery, e.g. due to
an FSF request timeout [fsrth_1] of the abort / TMF). If we cannot send, we
now get a trace record for the first "abrt_wt" or "[lt]r_wait" which denotes
almost the beginning of the callback.
No need to explicitly trace the wakeup after the above two blocking
functions because the next retry loop causes another trace in any case and
that is sufficient.
Example trace records formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : SCSI
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1
Tag : abrt_wt abort, before zfcp_erp_wait()
Request ID : 0x0000000000000000 none (invalid)
SCSI ID : 0x<scsi_id>
SCSI LUN : 0x<scsi_lun>
SCSI LUN high : 0x<scsi_lun_high>
SCSI result : 0x<scsi_result_of_cmd_to_be_aborted>
SCSI retries : 0x<retries_of_cmd_to_be_aborted>
SCSI allowed : 0x<allowed_retries_of_cmd_to_be_aborted>
SCSI scribble : 0x<req_id_of_cmd_to_be_aborted>
SCSI opcode : <CDB_of_cmd_to_be_aborted>
FCP rsp inf cod: 0x.. none (invalid)
FCP rsp IU : ... none (invalid)
Timestamp : ...
Area : SCSI
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1
Tag : lr_wait LUN reset, before zfcp_erp_wait()
Request ID : 0x0000000000000000 none (invalid)
SCSI ID : 0x<scsi_id>
SCSI LUN : 0x<scsi_lun>
SCSI LUN high : 0x<scsi_lun_high>
SCSI result : 0x... unrelated
SCSI retries : 0x.. unrelated
SCSI allowed : 0x.. unrelated
SCSI scribble : 0x... unrelated
SCSI opcode : ... unrelated
FCP rsp inf cod: 0x.. none (invalid)
FCP rsp IU : ... none (invalid)
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Fixes:
63caf367e1c9 ("[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp")
Fixes:
af4de36d911a ("[SCSI] zfcp: Block scsi_eh thread for rport state BLOCKED")
Cc: <stable@vger.kernel.org> #2.6.38+
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Steffen Maier [Thu, 17 May 2018 17:14:43 +0000 (19:14 +0200)]
scsi: zfcp: fix missing SCSI trace for result of eh_host_reset_handler
For problem determination we need to see whether and why we were successful
or not. This allows deduction of scsi_eh escalation.
Example trace record formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : SCSI
Subarea : 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1
Tag : schrh_r SCSI host reset handler result
Request ID : 0x0000000000000000 none (invalid)
SCSI ID : 0xffffffff none (invalid)
SCSI LUN : 0xffffffff none (invalid)
SCSI LUN high : 0xffffffff none (invalid)
SCSI result : 0x00002002 field re-used for midlayer value: SUCCESS
or in other cases: 0x2009 == FAST_IO_FAIL
SCSI retries : 0xff none (invalid)
SCSI allowed : 0xff none (invalid)
SCSI scribble : 0xffffffffffffffff none (invalid)
SCSI opcode :
ffffffff ffffffff ffffffff ffffffff none (invalid)
FCP rsp inf cod: 0xff none (invalid)
FCP rsp IU :
00000000 00000000 00000000 00000000 none (invalid)
00000000 00000000
v2.6.35 commit
a1dbfddd02d2 ("[SCSI] zfcp: Pass return code from
fc_block_scsi_eh to scsi eh") introduced the first return with something
other than the previously hardcoded single SUCCESS return path.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Fixes:
a1dbfddd02d2 ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh")
Cc: <stable@vger.kernel.org> #2.6.38+
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Uma Krishnan [Fri, 11 May 2018 19:06:19 +0000 (14:06 -0500)]
scsi: cxlflash: Isolate external module dependencies
Depending on the underlying transport, cxlflash has a dependency on either
the CXL or OCXL drivers, which are enabled via their Kconfig option.
Instead of having a module wide dependency on these config options, it is
better to isolate the object modules that are dependent on the CXL and OCXL
drivers and adjust the module dependencies accordingly.
This commit isolates the object files that are dependent on CXL and/or
OCXL. The cxl/ocxl fops used in the core driver are tucked under an ifdef to
avoid compilation errors.
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Uma Krishnan [Fri, 11 May 2018 19:06:05 +0000 (14:06 -0500)]
scsi: cxlflash: Abstract hardware dependent assignments
As a staging cleanup to support transport specific builds of the cxlflash
module, relocate device dependent assignments to header files. This will
avoid littering the core driver with conditional compilation logic.
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Uma Krishnan [Fri, 11 May 2018 19:05:51 +0000 (14:05 -0500)]
scsi: cxlflash: Add include guards to backend.h
The new header file, backend.h, that was recently added is missing the
include guards. This commit adds the guards.
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Matthew R. Ochs [Fri, 11 May 2018 19:05:37 +0000 (14:05 -0500)]
scsi: cxlflash: Use local mutex for AFU serialization
AFUs can only process a single AFU command at a time. This is enforced with
a global mutex situated within the AFU send routine. As this mutex has a
global scope, it has the potential to unnecessarily block commands destined
for other AFUs.
Instead of using a global mutex, transition the mutex to be per-AFU. This
will allow commands to only be blocked by siblings of the same AFU.
Signed-off-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Uma Krishnan [Fri, 11 May 2018 19:05:22 +0000 (14:05 -0500)]
scsi: cxlflash: Acquire semaphore before invoking ioctl services
When a superpipe process that makes use of virtual LUNs is terminated or
killed abruptly, there is a possibility that the cxlflash driver could hang
and deprive other operations on the adapter.
The release fop registered to be invoked on a context close, detaches every
LUN associated with the context. The underlying service to detach the LUN
assumes it has been called with the read semaphore held, and releases the
semaphore before any operation that could be time consuming.
When invoked without holding the read semaphore, an opportunity is created
for the semaphore's count to become negative when it is temporarily released
during one of these potential lengthy operations. This negative count
results in subsequent acquisition attempts taking forever, leading to the
hang.
To support the current design point of holding the semaphore on the ioctl()
paths, the release fop should acquire it before invoking any ioctl services.
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Uma Krishnan [Fri, 11 May 2018 19:05:08 +0000 (14:05 -0500)]
scsi: cxlflash: Limit the debug logs in the IO path
The kernel log can get filled with debug messages from send_cmd_ioarrin()
when dynamic debug is enabled for the cxlflash module and there is a lot of
legacy I/O traffic.
While these messages are necessary to debug issues that involve command
tracking, the abundance of data can overwrite other useful data in the
log. The best option available is to limit the messages that should serve
most of the common use cases.
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Uma Krishnan [Fri, 11 May 2018 19:04:46 +0000 (14:04 -0500)]
scsi: cxlflash: Yield to active send threads
The following Oops may be encountered if the device is reset, i.e. EEH
recovery, while there is heavy I/O traffic:
59:mon> t
[
c000200db64bb680]
c008000009264c40 cxlflash_queuecommand+0x3b8/0x500
[cxlflash]
[
c000200db64bb770]
c00000000090d3b0 scsi_dispatch_cmd+0x130/0x2f0
[
c000200db64bb7f0]
c00000000090fdd8 scsi_request_fn+0x3c8/0x8d0
[
c000200db64bb900]
c00000000067f528 __blk_run_queue+0x68/0xb0
[
c000200db64bb930]
c00000000067ab80 __elv_add_request+0x140/0x3c0
[
c000200db64bb9b0]
c00000000068daac blk_execute_rq_nowait+0xec/0x1a0
[
c000200db64bba00]
c00000000068dbb0 blk_execute_rq+0x50/0xe0
[
c000200db64bba50]
c0000000006b2040 sg_io+0x1f0/0x520
[
c000200db64bbaf0]
c0000000006b2e94 scsi_cmd_ioctl+0x534/0x610
[
c000200db64bbc20]
c000000000926208 sd_ioctl+0x118/0x280
[
c000200db64bbcc0]
c00000000069f7ac blkdev_ioctl+0x7fc/0xe30
[
c000200db64bbd20]
c000000000439204 block_ioctl+0x84/0xa0
[
c000200db64bbd40]
c0000000003f8514 do_vfs_ioctl+0xd4/0xa00
[
c000200db64bbde0]
c0000000003f8f04 SyS_ioctl+0xc4/0x130
[
c000200db64bbe30]
c00000000000b184 system_call+0x58/0x6c
When there is no room to send the I/O request, the cached room is refreshed
by reading the memory mapped command room value from the AFU. The AFU
register mapping is refreshed during a reset, creating a race condition that
can lead to the Oops above.
During a device reset, the AFU should not be unmapped until all the active
send threads quiesce. An atomic counter, cmds_active, is currently used to
track internal AFU commands and quiesce during reset. This same counter can
also be used for the active send threads.
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiaofei Tan [Wed, 9 May 2018 15:10:50 +0000 (23:10 +0800)]
scsi: hisi_sas: add check of device in hisi_sas_task_exec()
Currently we don't check that device is not gone before dereferencing
its elements in the function hisi_sas_task_exec() (specifically, the DQ
pointer).
This patch fixes this issue by filling in the DQ pointer in
hisi_sas_task_prep() after we check that the device pointer is still
safe to reference.
[mkp: typo]
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 9 May 2018 15:10:49 +0000 (23:10 +0800)]
scsi: hisi_sas: Use device lock to protect slot alloc/free
The IPTT of a slot is unique, and we currently use hisi_hba lock to
protect it.
Now slot is managed on hisi_sas_device.list, so use DQ lock to protect
for allocating and freeing the slot.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 9 May 2018 15:10:48 +0000 (23:10 +0800)]
scsi: hisi_sas: Don't lock DQ for complete task sending
Currently we lock the DQ to protect whole delivery process. So this
stops us building slots for the same queue in parallel, and can affect
performance.
To optimise it, only lock the DQ during special periods, specifically
when allocating a slot from the DQ and when delivering a slot to the HW.
This approach is now safe, thanks to the previous patches to ensure that
we always deliver a slot to the HW once allocated.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 9 May 2018 15:10:47 +0000 (23:10 +0800)]
scsi: hisi_sas: allocate slot buffer earlier
Currently we allocate the slot's memory buffer after allocating the DQ
slot.
To aid DQ lockout reduction, and allow slots to be built in parallel,
move this step (which can fail) prior to allocating the slot.
Also a stray spin_unlock_irqrestore() is removed from internal task exec
function.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 9 May 2018 15:10:46 +0000 (23:10 +0800)]
scsi: hisi_sas: make return type of prep functions void
Since the task prep functions now should not fail, adjust the return
types to void.
In addition, some checks in the task prep functions are relocated to the
main module; this is specifically the check for the number of elements
in an sg list exceeded the HW SGE limit.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 9 May 2018 15:10:45 +0000 (23:10 +0800)]
scsi: hisi_sas: relocate smp sg map
Currently we use DQ lock to protect delivery of DQ entry one by one.
To optimise to allow more than one slot to be built for a single DQ in
parallel, we need to remove the DQ lock when preparing slots, prior to
delivery.
To achieve this, we rearrange the slot build order to ensure that once
we allocate a slot for a task, we do cannot fail to deliver the task.
In this patch, we rearrange the slot building for SMP tasks to ensure
that sg mapping part (which can fail) happens before we allocate the
slot in the DQ.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Alim Akhtar [Sun, 6 May 2018 10:14:18 +0000 (15:44 +0530)]
scsi: ufs: make ufshcd_config_pwr_mode of non-static func
This makes ufshcd_config_pwr_mode non-static so that other vendors like
exynos can use it.
Signed-off-by: Seungwon Jeon <essuuj@gmail.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Alim Akhtar [Sun, 6 May 2018 10:14:17 +0000 (15:44 +0530)]
scsi: ufs: add quirk to enable host controller without hce
Some host controllers don't support host controller enable via HCE.
Signed-off-by: Seungwon Jeon <essuuj@gmail.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Alim Akhtar [Sun, 6 May 2018 10:14:16 +0000 (15:44 +0530)]
scsi: ufs: add quirk to disallow reset of interrupt aggregation
Some host controllers support interrupt aggregation but don't allow
resetting counter and timer in software.
Signed-off-by: Seungwon Jeon <essuuj@gmail.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Alim Akhtar [Sun, 6 May 2018 10:14:15 +0000 (15:44 +0530)]
scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr
In the right behavior, setting the bit to '0' indicates clear and '1'
indicates no change. If host controller handles this the other way,
UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used.
[mkp: typo]
Signed-off-by: Seungwon Jeon <essuuj@gmail.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: "Asutosh Das (asd)" <asutoshd@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Kees Cook [Wed, 2 May 2018 23:58:09 +0000 (16:58 -0700)]
scsi: ufs: ufshcd: Remove VLA usage
On the quest to remove all VLAs from the kernel[1] this moves buffers
off the stack. In the second instance, this collapses two separately
allocated buffers into a single buffer, since they are used
consecutively, which saves 256 bytes (QUERY_DESC_MAX_SIZE + 1) of stack
space.
[1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Luc Van Oostenryck [Tue, 24 Apr 2018 13:15:58 +0000 (15:15 +0200)]
scsi: mptlan: Fix mpt_lan_sdu_send()'s return type
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.
Fix this by returning 'netdev_tx_t' in this driver too.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Wen Xiong [Wed, 9 May 2018 18:47:54 +0000 (13:47 -0500)]
scsi: ipr: new IOASC update
This patch adds new adapter error log for P9 system with the new AZ SAS
cable.
Signed-off-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Acked-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Colin Ian King [Tue, 8 May 2018 21:54:35 +0000 (22:54 +0100)]
scsi: esas2r: fix spelling mistake: "requestss" -> "requests"
Trivial fix to spelling mistake in esas2r_debug message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Andrei Vagin [Thu, 22 Mar 2018 06:55:02 +0000 (23:55 -0700)]
scsi: target: target/file: Add support of direct and async I/O
There are two advantages:
* Direct I/O allows to avoid the write-back cache, so it reduces affects
to other processes in the system.
* Async I/O allows to handle a few commands concurrently.
DIO + AIO shows a better perfomance for random write operations:
Mode: O_DSYNC Async: 1
$ ./fio --bs=4K --direct=1 --rw=randwrite --ioengine=libaio --iodepth=64 --name=/dev/sda --runtime=20 --numjobs=2
WRITE: bw=45.9MiB/s (48.1MB/s), 21.9MiB/s-23.0MiB/s (22.0MB/s-25.2MB/s), io=919MiB (963MB), run=20002-20020msec
Mode: O_DSYNC Async: 0
$ ./fio --bs=4K --direct=1 --rw=randwrite --ioengine=libaio --iodepth=64 --name=/dev/sdb --runtime=20 --numjobs=2
WRITE: bw=1607KiB/s (1645kB/s), 802KiB/s-805KiB/s (821kB/s-824kB/s), io=31.8MiB (33.4MB), run=20280-20295msec
Known issue:
DIF (PI) emulation doesn't work when a target uses async I/O, because
DIF metadata is saved in a separate file, and it is another non-trivial
task how to synchronize writing in two files, so that a following read
operation always returns a consisten metadata for a specified block.
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Tested-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Signed-off-by: Andrei Vagin <avagin@openvz.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Kees Cook [Wed, 2 May 2018 22:55:45 +0000 (15:55 -0700)]
scsi: libosd: Remove VLA usage
On the quest to remove all VLAs from the kernel[1] this rearranges the
code to avoid a VLA warning under -Wvla (gcc doesn't recognize "const"
variables as not triggering VLA creation). Additionally cleans up
variable naming to avoid 80 character column limit.
[1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Boaz Harrosh <ooo@electrozaur.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Zhu Lingshan [Wed, 2 May 2018 03:13:44 +0000 (11:13 +0800)]
scsi: tcmu: refactor nl wr_cache attr with new helpers
use new netlink events helpers tcmu_netlink_init() and
tcmu_netlink_send() to refactor netlink event attribute
TCMU_ATTR_WRITECACHE(belongs to TCMU_CMD_RECONFIG_DEVICE) which is also
emulate_write_cache in configFS.
Removed tcmu_netlink_event() since we have new netlink
events helpers now.
Signed-off-by: Zhu Lingshan <lszhu@suse.com>
Acked-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Zhu Lingshan [Wed, 2 May 2018 03:13:43 +0000 (11:13 +0800)]
scsi: tcmu: refactor nl dev_size attr with new helpers
use new netlink events helpers tcmu_netlink_init() and
tcmu_netlink_send() to refactor netlink event attribute
TCMU_ATTR_DEV_SIZE(belongs to TCMU_CMD_RECONFIG_DEVICE) which is also
dev_size in configFS.
Signed-off-by: Zhu Lingshan <lszhu@suse.com>
Acked-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Zhu Lingshan [Wed, 2 May 2018 03:13:42 +0000 (11:13 +0800)]
scsi: tcmu: refactor nl dev_cfg attr with new nl helpers
use new netlink events helpers tcmu_netlink_init() and
tcmu_netlink_send() to refactor netlink event attribute
TCMU_ATTR_DEV_CFG(belongs to TCMU_CMD_RECONFIG_DEVICE) which is also
dev_config in configFS.
Signed-off-by: Zhu Lingshan <lszhu@suse.com>
Acked-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Zhu Lingshan [Wed, 2 May 2018 03:13:41 +0000 (11:13 +0800)]
scsi: tcmu: refactor rm_device cmd with new nl helpers
use new netlink events helpers tcmu_netlink_init() and
tcmu_netlink_send() to refactor netlink event TCMU_CMD_REMOVED_DEVICE
Signed-off-by: Zhu Lingshan <lszhu@suse.com>
Acked-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Zhu Lingshan [Wed, 2 May 2018 03:13:40 +0000 (11:13 +0800)]
scsi: tcmu: refactor add_device cmd with new nl helpers
use new netlink events helpers tcmu_netlink_init() and
tcmu_netlink_send() to refactor netlink event TCMU_CMD_ADDED_DEVICE
Signed-off-by: Zhu Lingshan <lszhu@suse.com>
Acked-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Zhu Lingshan [Wed, 2 May 2018 03:13:39 +0000 (11:13 +0800)]
scsi: tcmu: add new netlink events helpers
Add new netlink events helpers tcmu_netlink_event_init() and
tcmu_netlink_event_send(). These new functions intend to replace
existing netlink events helper function tcmu_netlink_event().
The existing function tcmu_netlink_event() works well for events like
TCMU_ADDED_DEVICE and TCMU_REMOVED_DEVICE which only has one netlink
attribute. But if there is a command requires more than one attributes
to send out, we have to use a struct to adapt the paremeter
reconfig_data, it is hard to use one struct or a union in one struct to
adapt every command with different attributes, it may get long and ugly.
With the new two functions, we can call tcmu_netlink_event_init() to
initialize a netlink event, then add all attributes we need by using
nla_put_xxx(), at last use tcmu_netlink_event_send() to send it out. So
that we don't need to use a long struct or union if we want to send
mulitple attributes for different commands.
[mkp: typos]
Signed-off-by: Zhu Lingshan <lszhu@suse.com>
Acked-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Wenwen Wang [Tue, 8 May 2018 00:54:01 +0000 (19:54 -0500)]
scsi: 3w-xxxx: fix a missing-check bug
In tw_chrdev_ioctl(), the length of the data buffer is firstly copied
from the userspace pointer 'argp' and saved to the kernel object
'data_buffer_length'. Then a security check is performed on it to make
sure that the length is not more than 'TW_MAX_IOCTL_SECTORS *
512'. Otherwise, an error code -EINVAL is returned. If the security
check is passed, the entire ioctl command is copied again from the
'argp' pointer and saved to the kernel object 'tw_ioctl'. Then, various
operations are performed on 'tw_ioctl' according to the 'cmd'. Given
that the 'argp' pointer resides in userspace, a malicious userspace
process can race to change the buffer length between the two
copies. This way, the user can bypass the security check and inject
invalid data buffer length. This can cause potential security issues in
the following execution.
This patch checks for capable(CAP_SYS_ADMIN) in tw_chrdev_open() to
avoid the above issues.
Signed-off-by: Wenwen Wang <wang6495@umn.edu>
Acked-by: Adam Radford <aradford@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Wenwen Wang [Tue, 8 May 2018 00:46:43 +0000 (19:46 -0500)]
scsi: 3w-9xxx: fix a missing-check bug
In twa_chrdev_ioctl(), the ioctl driver command is firstly copied from
the userspace pointer 'argp' and saved to the kernel object
'driver_command'. Then a security check is performed on the data buffer
size indicated by 'driver_command', which is
'driver_command.buffer_length'. If the security check is passed, the
entire ioctl command is copied again from the 'argp' pointer and saved
to the kernel object 'tw_ioctl'. Then, various operations are performed
on 'tw_ioctl' according to the 'cmd'. Given that the 'argp' pointer
resides in userspace, a malicious userspace process can race to change
the buffer size between the two copies. This way, the user can bypass
the security check and inject invalid data buffer size. This can cause
potential security issues in the following execution.
This patch checks for capable(CAP_SYS_ADMIN) in twa_chrdev_open()t o
avoid the above issues.
Signed-off-by: Wenwen Wang <wang6495@umn.edu>
Acked-by: Adam Radford <aradford@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Tomohiro Kusumi [Fri, 4 May 2018 23:45:29 +0000 (16:45 -0700)]
scsi: mpt3sas: fix header path in ioctl documentation
MPT2_MAGIC_NUMBER as well as drivers/scsi/mpt2sas/mpt2sas_ctl.h were
removed to reuse mpt3sas code since commit
09ec55ed74 ("mpt2sas: Remove
.c and .h files from mpt2sas driver").
Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@osnexus.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Tomohiro Kusumi [Fri, 4 May 2018 23:45:28 +0000 (16:45 -0700)]
scsi: mpt3sas: remove obsolete path "drivers/scsi/mpt2sas/" from MAINTAINERS
drivers/scsi/mpt2sas/ no longer exists after commit
c84b06a48c ("mpt3sas: Single driver module which supports both SAS 2.0 &
SAS 3.0 HBAs") merged/removed it.
Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@osnexus.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dan Carpenter [Thu, 3 May 2018 10:54:32 +0000 (13:54 +0300)]
scsi: megaraid: silence a static checker bug
If we had more than 32 megaraid cards then it would cause memory
corruption. That's not likely, of course, but it's handy to enforce it
and make the static checker happy.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Colin Ian King [Thu, 3 May 2018 10:18:07 +0000 (11:18 +0100)]
scsi: mptsas: fix spelling mistake: "matchs" -> "matches"
Trivial fix to spelling mistake in warning message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Colin Ian King [Thu, 3 May 2018 09:26:12 +0000 (10:26 +0100)]
scsi: lpfc: fix spelling mistakes: "mabilbox" and "maibox"
Trivial fix to spelling mistakes in lpfc_printf_log log message
"mabilbox" -> "mailbox"
"maibox" -> "mailbox"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Andrei Vagin [Wed, 2 May 2018 20:31:13 +0000 (13:31 -0700)]
scsi: qla2xxx: remove the unused tcm_qla2xxx_cmd_wq
Signed-off-by: Andrei Vagin <avagin@openvz.org>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Colin Ian King [Wed, 2 May 2018 09:12:43 +0000 (10:12 +0100)]
scsi: mptfusion: fix spelling mistake: "initators" -> "initiators"
Trivial fix to spelling mistake in text string.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiaofei Tan [Wed, 2 May 2018 15:56:34 +0000 (23:56 +0800)]
scsi: hisi_sas: workaround a v3 hw hilink bug
There is an SoC bug of v3 hw development version. When hot- unplugging a
directly attached disk, the PHY down interrupt may not happen. It is
very easy to appear on some boards.
When this issue occurs, the controller will receive many invalid dword
frames, and the "alos" fields of register HILINK_ERR_DFX can indicate
that disk was unplugged.
As an workaround solution, this patch detects this issue in the channel
interrupt, and workaround it by following steps:
- Disable the PHY
- Clear error code and interrupt
- Enable the PHY
Then the HW will reissue PHY down interrupt.
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
John Garry [Wed, 2 May 2018 15:56:33 +0000 (23:56 +0800)]
scsi: hisi_sas: add readl poll timeout helper wrappers
It is common to use readl poll timeout helpers in the driver, so create
custom wrappers.
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiaofei Tan [Wed, 2 May 2018 15:56:32 +0000 (23:56 +0800)]
scsi: hisi_sas: remove redundant handling to event95 for v3
Event95 is used for DFX purpose. The relevant bit for this interrupt in
the ENT_INT_SRC_MSK3 register has been disabled, so remove the
processing.
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 2 May 2018 15:56:31 +0000 (23:56 +0800)]
scsi: hisi_sas: config ATA de-reset as an constrained command for v3 hw
As a unconstrained command, a command can be sent to SATA disk even if
SATA disk status is BUSY, ERR or DRQ.
If an ATA reset assert is successful but ATA reset de-assert fails, then
it will retry the reset de-assert. If reset de- assert retry is
successful, we think it is okay to probe the device but actually it
still has Err status.
Apparently we need to retry the ATA reset assertion and de- assertion
instead for this mentioned scenario.
As such, we config ATA reset assert as a constrained command, if ATA
reset de-assert fails, then ATA reset de-assert retry will also
fail. Then we will retry the proper process of ATA reset assert and
de-assert again.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 2 May 2018 15:56:30 +0000 (23:56 +0800)]
scsi: hisi_sas: update PHY linkrate after a controller reset
After the controller is reset, we currently may not honour the PHY max
linkrate set via sysfs, in that after a reset we always revert to max
linkrate of 12Gbps, ignoring the value set via sysfs.
This patch modifies to policy to set the programmed PHY linkrate,
honouring the max linkrate programmed via sysfs.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
John Garry [Wed, 2 May 2018 15:56:29 +0000 (23:56 +0800)]
scsi: hisi_sas: stop controller timer for reset
We should only have the timer enabled after PHY up after controller
reset, so disable prior to reset.
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 2 May 2018 15:56:28 +0000 (23:56 +0800)]
scsi: hisi_sas: check sas_dev gone earlier in hisi_sas_abort_task()
It is possible to dereference a NULL-pointer in hisi_sas_abort_task() in
special scenario when the device has been removed.
If an SMP task times-out, it will call hisi_sas_abort_task() to
recover. And currently there is a check in hisi_sas_abort_task() to
avoid the situation of processing the abort for the removed device.
However we have an ordering problem, in that we may reference a task for
the removed device before checking if the device has been removed.
Fix this by only referencing the sas_dev after we know it is still
present.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 2 May 2018 15:56:27 +0000 (23:56 +0800)]
scsi: hisi_sas: fix PI memory size
There are 28 bytes of protection information record of SSP for v3 hw, 16
bytes for v2 hw, and probably 24 for v1 hw (forgotten now).
So use a value big enough in hisi_sas_command_table_ssp.prot to cover
all cases.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 2 May 2018 15:56:26 +0000 (23:56 +0800)]
scsi: hisi_sas: check host frozen before calling "done" function
When the host is frozen in SCSI EH state, at any point after the LLDD
sets SAS_TASK_STATE_DONE for the sas_task task state, libsas may free
the task; see sas_scsi_find_task().
This puts the LLDD in a difficult position, in that once it sets
SAS_TASK_STATE_DONE for the task state it should not reference the
sas_task again. But the LLDD needs will check the sas_task indirectly in
calling task->task_done()->sas_scsi_task_done() or sas_ata_task_done()
(to check if the host is frozen state actually).
And the LLDD cannot set SAS_TASK_STATE_DONE for the task state after
task->task_done() is called (as the sas_task is free'd at this point).
This situation would seem to be a problem made by libsas.
To work around, check in the LLDD whether the host is in frozen state to
ensure it is ok to call task->task_done() function. If in the frozen
state, we rely on SCSI EH and libsas to free the sas_task directly.
We do not do this for the following IO types:
- SMP - they are managed in libsas directly, outside SCSI EH
- Any internally originated IO, for similar reason
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 2 May 2018 15:56:25 +0000 (23:56 +0800)]
scsi: hisi_sas: Add some checks to avoid free'ing a sas_task twice
If the SCSI host enters EH, any pending IO will be processed by SCSI
EH. However it is possible that SCSI EH will try to abort the IO and
also at the same time the IO completes in the driver. In this situation
there is a small chance of freeing the sas_task twice.
Then if another IO re-uses freed sas_task before the second time of
free'ing sas_task, it is possible to free incorrect sas_task.
To avoid this situation, add some checks to increase reliability. The
sas_task task state flag SAS_TASK_STATE_ABORTED is used to mutually
protect the LLDD and libsas freeing the task.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Xiang Chen [Wed, 2 May 2018 15:56:24 +0000 (23:56 +0800)]
scsi: hisi_sas: optimise the usage of DQ locking
In the DQ tasklet processing it is not necessary to take the DQ lock, as
there is no contention between adding slots to the CQ and removing slots
from the matching DQ.
In addition, since we run each DQ in a separate tasklet context, there
would be no possible contention between DQ processing running for the
same queue in parallel.
It is still necessary to take hisi_hba lock when free'ing slots.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
projects / platform / kernel / linux-rpi.git / log