From patchwork Tue Jun 30 06:54:49 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sreekanth Reddy X-Patchwork-Id: 6693771 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 0F4A0C05AC for ; Tue, 30 Jun 2015 06:56:01 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0F22B2042A for ; Tue, 30 Jun 2015 06:56:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EACB6203F4 for ; Tue, 30 Jun 2015 06:55:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753026AbbF3Gzu (ORCPT ); Tue, 30 Jun 2015 02:55:50 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:35682 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752813AbbF3Gzi (ORCPT ); Tue, 30 Jun 2015 02:55:38 -0400 Received: by pactm7 with SMTP id tm7so644634pac.2 for ; Mon, 29 Jun 2015 23:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=avagotech.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=4HewvBCbOFe2zzfgpIC4die05q70Tp7ECTXysa61Nbk=; b=Myp0xI35yEfDLBhwMWg3ifkSmHM14IbTym1I9sFaQhYw+13sBoKeSzQf2b9EF3D8+l Fige8nsw0aajYXKTC2TeWnUH3LPjC8w+138S020wCD/zewaDbCEh8jeA0+1F+hY/CGxX yN9zS/6RdMr3AIMUYbXsktKLaHyMtl3zOE14Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=4HewvBCbOFe2zzfgpIC4die05q70Tp7ECTXysa61Nbk=; b=kXGFVXgzvuYfllhcElkR8InktY6cB3G+/8KMDLBtTQo0mQZcVkQBryyygyh9qianV7 hl1dcPthMpMbAq9+PEXkPBFJanNB7pTfx2DMpxIw/Yu8auRg0jEW+Ukes49AvwURKDeT VHVw7/Yl8LKfStKg2PAFs+A4QkjwfK59e6CKpRhMgkZ4QPAR6HCQ+LyLjFVK3ZgVw1tB bZqHHi0uJ/8HMKgoSYKkZ+JETXErproL+OLky6/TmRJKq4wm2oURw5TswxP4Hvz5pFRT 6/K+N7WI+e/yMfjFSBaU669UaWWg5huEsZVA2K8N0Yvi7EoC/2lwq8AW5sqUL/TsRTcM AC+g== X-Gm-Message-State: ALoCoQlrYetuclUMvh03nkGNIo9MyL/ktP4X07H1NgR83OgPLMePI91Dj+5IDEvR+zrLmk4eI3w8 X-Received: by 10.68.197.102 with SMTP id it6mr40530977pbc.65.1435647336488; Mon, 29 Jun 2015 23:55:36 -0700 (PDT) Received: from host1.lsi.com ([192.19.239.250]) by mx.google.com with ESMTPSA id 1sm935543pds.79.2015.06.29.23.55.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Jun 2015 23:55:35 -0700 (PDT) From: Sreekanth Reddy X-Google-Original-From: Sreekanth Reddy To: jejb@kernel.org, hch@infradead.org Cc: martin.petersen@oracle.com, linux-scsi@vger.kernel.org, JBottomley@Parallels.com, Sathya.Prakash@avagotech.com, linux-kernel@vger.kernel.org, jthumshirn@suse.de, Sreekanth Reddy Subject: [PATCH v2 03/20] [SCSI] mpt3sas: Don't block the drive when drive addition under the control of SML Date: Tue, 30 Jun 2015 12:24:49 +0530 Message-Id: <1435647306-36956-4-git-send-email-Sreekanth.Reddy@avagotech.com> X-Mailer: git-send-email 2.0.2 In-Reply-To: <1435647306-36956-1-git-send-email-Sreekanth.Reddy@avagotech.com> References: <1435647306-36956-1-git-send-email-Sreekanth.Reddy@avagotech.com> Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP During hot-plugging of a disk(having a flaky link), the disk addition stops and any further disk addition or removal doesn't happen on that controller. This is because, when driver receives DELAY_NOT_RESPONDING event for a disk while it is undergoing addition at the SCSI Transport layer, the driver would block the I/O to that disk resulting in a deadlock. i.e the disk addition work couldn't be completed at the SCSI Transport Layer as it can't send any I/Os (such as Inquiry, Report LUNs etc) to the disk as I/Os are blocked to this drive. Also any subsequent device removal (TARGET_NOT_RESPONDING) or link update(RC_PHY_CHANGED) event couldn't be processed as they are in the queue to get processed after disk addition event. Description of Change: Don't block the drive when drive addition is under the control of SML. So that SML won't be blocked of issuing the device dicovery commands (such as Inquiry, Report LUNs etc). Changes in v2: Patch version change only. Signed-off-by: Sreekanth Reddy Reviewed-by: Martin K. Petersen --- drivers/scsi/mpt3sas/mpt3sas_base.h | 4 +++- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 7 +++++++ drivers/scsi/mpt3sas/mpt3sas_transport.c | 18 ++++++++++++++++++ 3 files changed, 28 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h index a7386ee..01d92db 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.h +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h @@ -301,7 +301,8 @@ struct _internal_cmd { * @responding: used in _scsih_sas_device_mark_responding * @fast_path: fast path feature enable bit * @pfa_led_on: flag for PFA LED status - * + * @pend_sas_rphy_add: flag to check if device is in sas_rphy_add() + * addition routine. */ struct _sas_device { struct list_head list; @@ -322,6 +323,7 @@ struct _sas_device { u8 responding; u8 fast_path; u8 pfa_led_on; + u8 pend_sas_rphy_add; }; /** diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c index 5a97e32..d457dba 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -2644,6 +2644,11 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16 handle) { struct MPT3SAS_DEVICE *sas_device_priv_data; struct scsi_device *sdev; + struct _sas_device *sas_device; + + sas_device = _scsih_sas_device_find_by_handle(ioc, handle); + if (!sas_device) + return; shost_for_each_device(sdev, ioc->shost) { sas_device_priv_data = sdev->hostdata; @@ -2653,6 +2658,8 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16 handle) continue; if (sas_device_priv_data->block) continue; + if (sas_device->pend_sas_rphy_add) + continue; sas_device_priv_data->block = 1; scsi_internal_device_block(sdev); sdev_printk(KERN_INFO, sdev, diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c b/drivers/scsi/mpt3sas/mpt3sas_transport.c index efb98af..7a7aa68 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_transport.c +++ b/drivers/scsi/mpt3sas/mpt3sas_transport.c @@ -649,6 +649,7 @@ mpt3sas_transport_port_add(struct MPT3SAS_ADAPTER *ioc, u16 handle, unsigned long flags; struct _sas_node *sas_node; struct sas_rphy *rphy; + struct _sas_device *sas_device = NULL; int i; struct sas_port *port; @@ -731,10 +732,27 @@ mpt3sas_transport_port_add(struct MPT3SAS_ADAPTER *ioc, u16 handle, mpt3sas_port->remote_identify.device_type); rphy->identify = mpt3sas_port->remote_identify; + + if (mpt3sas_port->remote_identify.device_type == SAS_END_DEVICE) { + sas_device = mpt3sas_scsih_sas_device_find_by_sas_address(ioc, + mpt3sas_port->remote_identify.sas_address); + if (!sas_device) { + dfailprintk(ioc, printk(MPT3SAS_FMT + "failure at %s:%d/%s()!\n", + ioc->name, __FILE__, __LINE__, __func__)); + goto out_fail; + } + sas_device->pend_sas_rphy_add = 1; + } + if ((sas_rphy_add(rphy))) { pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n", ioc->name, __FILE__, __LINE__, __func__); } + + if (mpt3sas_port->remote_identify.device_type == SAS_END_DEVICE) + sas_device->pend_sas_rphy_add = 0; + if ((ioc->logging_level & MPT_DEBUG_TRANSPORT)) dev_printk(KERN_INFO, &rphy->dev, "add: handle(0x%04x), sas_addr(0x%016llx)\n",