Patch "scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled" has been added to the 3.18-stable tree
Subsystems (3)
This is a note to let you know that I've just added the patch titled
scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
scsi-zfcp-fix-queuecommand-for-scsi_eh-commands-when-dix-enabled.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
71b8e45da51a7b64a23378221c0a5868bd79da4fMon Sep 17 00:00:00 2001
From: Steffen Maier <[email protected]>
Date: Fri, 28 Jul 2017 12:30:51 +0200
Subject: scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled
From: Steffen Maier <[email protected]>
commit 71b8e45da51a7b64a23378221c0a5868bd79da4f upstream.
Since commit db007fc5e20c ("[SCSI] Command protection operation"), scsi_eh_prep_cmnd() saves scmd->prot_op and temporarily resets it to SCSI_PROT_NORMAL.
Other FCP LLDDs such as qla2xxx and lpfc shield their queuecommand() to only access any of scsi_prot_sg...() if (scsi_get_prot_op(cmd) != SCSI_PROT_NORMAL).
Do the same thing for zfcp, which introduced DIX support with commit ef3eb71d8ba4 ("[SCSI] zfcp: Introduce experimental support for DIF/DIX").
Otherwise, TUR SCSI commands as part of scsi_eh likely fail in zfcp, because the regular SCSI command with DIX protection data, that scsi_eh re-uses in scsi_send_eh_cmnd(), of course still has (scsi_prot_sg_count() != 0) and so zfcp sends down bogus requests to the FCP channel hardware.
This causes scsi_eh_test_devices() to have (finish_cmds == 0) [not SCSI device is online or not scsi_eh_tur() failed]
so regular SCSI commands, that caused / were affected by scsi_eh, are moved to work_q and scsi_eh_test_devices() itself returns false. In turn, it unnecessarily escalates in our case in scsi_eh_ready_devs() beyond host reset to finally scsi_eh_offline_sdevs()
which sets affected SCSI devices offline with the following kernel message:
"kernel: sd H:0:T:L: Device offlined - not ready after error recovery"
--- drivers/s390/scsi/zfcp_fsf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/s390/scsi/zfcp_fsf.c +2 -1
@@ -2247,7 +2247,8 @@ int zfcp_fsf_fcp_cmnd(struct scsi_cmnd * fcp_cmnd = (struct fcp_cmnd *) &req->qtcb->bottom.io.fcp_cmnd;zfcp_fc_scsi_to_fcp (fcp_cmnd, scsi_cmnd,0 ); -if (scsi_prot_sg_count (scsi_cmnd)) { +if ((scsi_get_prot_op (scsi_cmnd) !=SCSI_PROT_NORMAL ) && +scsi_prot_sg_count (scsi_cmnd)) {zfcp_qdio_set_data_div (qdio, &req->qdio_req,scsi_prot_sg_count (scsi_cmnd)); retval = zfcp_qdio_sbals_from_sg(qdio, &req->qdio_req,
Patches currently in stable-queue which might be from [email protected] are
queue-3.18/scsi-zfcp-add-handling-for-fcp_resid_over-to-the-fcp-ingress-path.patch queue-3.18/scsi-zfcp-trace-high-part-of-new-64-bit-scsi-lun.patch queue-3.18/scsi-zfcp-fix-queuecommand-for-scsi_eh-commands-when-dix-enabled.patch queue-3.18/scsi-zfcp-fix-payload-with-full-fcp_rsp-iu-in-scsi-trace-records.patch queue-3.18/scsi-zfcp-trace-hba-fsf-response-by-default-on-dismiss-or-timedout-late-response.patch queue-3.18/scsi-zfcp-fix-missing-trace-records-for-early-returns-in-tmf-eh-handlers.patch