From patchwork Thu May 17 17:14:55 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steffen Maier X-Patchwork-Id: 10407295 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6DB19602C2 for ; Thu, 17 May 2018 17:16:08 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5D94128574 for ; Thu, 17 May 2018 17:16:08 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 525E1285E2; Thu, 17 May 2018 17:16:08 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DBD2C28574 for ; Thu, 17 May 2018 17:16:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752307AbeEQRQF (ORCPT ); Thu, 17 May 2018 13:16:05 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:35072 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752272AbeEQRQD (ORCPT ); Thu, 17 May 2018 13:16:03 -0400 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4HHENGM144160 for ; Thu, 17 May 2018 13:16:03 -0400 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j1bf1054j-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 17 May 2018 13:16:03 -0400 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 17 May 2018 18:15:59 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 17 May 2018 18:15:56 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4HHFti85701976; Thu, 17 May 2018 17:15:55 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1B19F4C052; Thu, 17 May 2018 18:07:44 +0100 (BST) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C58D34C046; Thu, 17 May 2018 18:07:43 +0100 (BST) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Thu, 17 May 2018 18:07:43 +0100 (BST) From: Steffen Maier To: "James E . J . Bottomley" , "Martin K . Petersen" Cc: linux-scsi@vger.kernel.org, linux-s390@vger.kernel.org, Benjamin Block , Martin Schwidefsky , Heiko Carstens , Steffen Maier Subject: [PATCH 13/25] zfcp: decouple TMFs from scsi_cmnd by using fc_block_rport Date: Thu, 17 May 2018 19:14:55 +0200 X-Mailer: git-send-email 2.16.3 In-Reply-To: <20180517171507.18237-1-maier@linux.ibm.com> References: <20180517171507.18237-1-maier@linux.ibm.com> X-TM-AS-GCONF: 00 x-cbid: 18051717-0044-0000-0000-0000055397D6 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18051717-0045-0000-0000-000028950DC4 Message-Id: <20180517171507.18237-14-maier@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-17_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805170161 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 Reviewed-by: Benjamin Block --- Notes: Changes since RFC: For consistency renamed from "zfcp: use fc_block_rport for TMFs and host reset to decouple from scsi_cmnd". zfcp_scsi_eh_host_reset_handler() will be converted in a later patch. Therefore, this patch here does not touch the host reset case any more. Since the previous "[RFC 6/9] scsi: fc: start decoupling fc_block_scsi_eh from scsi_cmnd" was queued for 4.14 already, I dropped it from this new patch set version and simply depend on it. Intentionally retrieve the rport by walking SCSI common code objects rather than zfcp_sdev->port->rport. This also fixes the problem that we could not synchronize if port->rport is NULL but still continued as if the TMF was successful as Hannes correctly pointed out. drivers/s390/scsi/zfcp_scsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/s390/scsi/zfcp_scsi.c b/drivers/s390/scsi/zfcp_scsi.c index e77e43a0630a..e0c5735cf3db 100644 --- a/drivers/s390/scsi/zfcp_scsi.c +++ b/drivers/s390/scsi/zfcp_scsi.c @@ -270,6 +270,7 @@ static int zfcp_task_mgmt_function(struct scsi_cmnd *scpnt, u8 tm_flags) struct scsi_device *sdev = scpnt->device; struct zfcp_scsi_dev *zfcp_sdev = sdev_to_zfcp(sdev); struct zfcp_adapter *adapter = zfcp_sdev->port->adapter; + struct fc_rport *rport = starget_to_rport(scsi_target(sdev)); struct zfcp_fsf_req *fsf_req = NULL; int retval = SUCCESS, ret; int retry = 3; @@ -281,7 +282,7 @@ static int zfcp_task_mgmt_function(struct scsi_cmnd *scpnt, u8 tm_flags) zfcp_dbf_scsi_devreset("wait", sdev, tm_flags, NULL); zfcp_erp_wait(adapter); - ret = fc_block_scsi_eh(scpnt); + ret = fc_block_rport(rport); if (ret) { zfcp_dbf_scsi_devreset("fiof", sdev, tm_flags, NULL); return ret;