From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:48365 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932243AbcJZIQ0 (ORCPT ); Wed, 26 Oct 2016 04:16:26 -0400 Subject: Patch "zfcp: fix ELS/GS request&response length for hardware data router" has been added to the 4.4-stable tree To: maier@linux.vnet.ibm.com, bblock@linux.vnet.ibm.com, gregkh@linuxfoundation.org, hare@suse.com, martin.petersen@oracle.com Cc: , From: Date: Wed, 26 Oct 2016 10:15:47 +0200 Message-ID: <14774697475555@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled zfcp: fix ELS/GS request&response length for hardware data router to the 4.4-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: zfcp-fix-els-gs-request-response-length-for-hardware-data-router.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From 70369f8e15b220f50a16348c79a61d3f7054813c Mon Sep 17 00:00:00 2001 From: Steffen Maier Date: Wed, 10 Aug 2016 18:30:45 +0200 Subject: zfcp: fix ELS/GS request&response length for hardware data router From: Steffen Maier commit 70369f8e15b220f50a16348c79a61d3f7054813c upstream. In the hardware data router case, introduced with kernel 3.2 commit 86a9668a8d29 ("[SCSI] zfcp: support for hardware data router") the ELS/GS request&response length needs to be initialized as in the chained SBAL case. Otherwise, the FCP channel rejects ELS requests with FSF_REQUEST_SIZE_TOO_LARGE. Such ELS requests can be issued by user space through BSG / HBA API, or zfcp itself uses ADISC ELS for remote port link test on RSCN. The latter can cause a short path outage due to unnecessary remote target port recovery because the always failing ADISC cannot detect extremely short path interruptions beyond the local FCP channel. Below example is decoded with zfcpdbf from s390-tools: Timestamp : ... Area : SAN Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : zfcp_dbf_san_req+0408 Record id : 1 Tag : fssels1 Request id : 0x Destination ID : 0x00 Payload info : 52000000 00000000 [ADISC] 00 00000000 00000000 00000000 00000000 00000000 Timestamp : ... Area : HBA Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : zfcp_dbf_hba_fsf_res+0740 Record id : 1 Tag : fs_ferr Request id : 0x Request status : 0x00000010 FSF cmnd : 0x0000000b [FSF_QTCB_SEND_ELS] FSF sequence no: 0x... FSF issued : ... FSF stat : 0x00000061 [FSF_REQUEST_SIZE_TOO_LARGE] FSF stat qual : 00000000 00000000 00000000 00000000 Prot stat : 0x00000100 Prot stat qual : 00000000 00000000 00000000 00000000 Signed-off-by: Steffen Maier Fixes: 86a9668a8d29 ("[SCSI] zfcp: support for hardware data router") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman --- drivers/s390/scsi/zfcp_fsf.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/s390/scsi/zfcp_fsf.c +++ b/drivers/s390/scsi/zfcp_fsf.c @@ -984,8 +984,12 @@ static int zfcp_fsf_setup_ct_els_sbals(s if (zfcp_adapter_multi_buffer_active(adapter)) { if (zfcp_qdio_sbals_from_sg(qdio, &req->qdio_req, sg_req)) return -EIO; + qtcb->bottom.support.req_buf_length = + zfcp_qdio_real_bytes(sg_req); if (zfcp_qdio_sbals_from_sg(qdio, &req->qdio_req, sg_resp)) return -EIO; + qtcb->bottom.support.resp_buf_length = + zfcp_qdio_real_bytes(sg_resp); zfcp_qdio_set_data_div(qdio, &req->qdio_req, zfcp_qdio_sbale_count(sg_req)); Patches currently in stable-queue which might be from maier@linux.vnet.ibm.com are queue-4.4/zfcp-fix-els-gs-request-response-length-for-hardware-data-router.patch queue-4.4/zfcp-trace-on-request-for-open-and-close-of-wka-port.patch queue-4.4/zfcp-close-window-with-unblocked-rport-during-rport-gone.patch queue-4.4/zfcp-retain-trace-level-for-scsi-and-hba-fsf-response-records.patch queue-4.4/zfcp-restore-dont-use-0-to-indicate-invalid-lun-in-rec-trace.patch queue-4.4/zfcp-fix-fc_host-port_type-with-npiv.patch queue-4.4/zfcp-fix-d_id-field-with-actual-value-on-tracing-san-responses.patch queue-4.4/zfcp-fix-payload-trace-length-for-san-request-response.patch queue-4.4/scsi-zfcp-spin_lock_irqsave-is-not-nestable.patch queue-4.4/zfcp-restore-tracing-of-handle-for-port-and-lun-with-hba-records.patch queue-4.4/zfcp-trace-full-payload-of-all-san-records-req-resp-iels.patch