From patchwork Wed Apr 26 18:53:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bart Van Assche X-Patchwork-Id: 9701875 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 BF9A9603F6 for ; Wed, 26 Apr 2017 18:54:08 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AE40428459 for ; Wed, 26 Apr 2017 18:54:08 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A21232847F; Wed, 26 Apr 2017 18:54: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=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 8C5F928459 for ; Wed, 26 Apr 2017 18:54:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932261AbdDZSyH (ORCPT ); Wed, 26 Apr 2017 14:54:07 -0400 Received: from esa6.hgst.iphmx.com ([216.71.154.45]:28953 "EHLO esa6.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932169AbdDZSyF (ORCPT ); Wed, 26 Apr 2017 14:54:05 -0400 X-IronPort-AV: E=Sophos;i="5.37,255,1488816000"; d="scan'208,223";a="14113299" Received: from mail-sn1nam02lp0022.outbound.protection.outlook.com (HELO NAM02-SN1-obe.outbound.protection.outlook.com) ([216.32.180.22]) by ob1.hgst.iphmx.com with ESMTP; 27 Apr 2017 02:54:04 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharedspace.onmicrosoft.com; s=selector1-sharedspace-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NapIM9UBOzKikGKgxVq2eZQO9j3JCLyvEwSqEJ9tgfM=; b=NMLnUNO7Nj7hTY5yLIXfs+qR2Y/7kK3UnJNqtLU4NZFQNuyYqH9FmGHvuHD08FIMimGSHcUEa2NBWBCByugkWM1AI4Q/pH+3iim9QPfLG1SdmCWMhOtAZXgdq0Gt+5zuF9zmjVW7JenzyuDVnG3ktPhd+4MYNLJu4sMoyEL9BTU= Received: from CY1PR0401MB1536.namprd04.prod.outlook.com (10.163.19.154) by CY1PR0401MB1535.namprd04.prod.outlook.com (10.163.19.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Wed, 26 Apr 2017 18:54:01 +0000 Received: from CY1PR0401MB1536.namprd04.prod.outlook.com ([10.163.19.154]) by CY1PR0401MB1536.namprd04.prod.outlook.com ([10.163.19.154]) with mapi id 15.01.1047.019; Wed, 26 Apr 2017 18:54:00 +0000 From: Bart Van Assche To: "James.Bottomley@HansenPartnership.com" , "bblock@linux.vnet.ibm.com" CC: "linux-scsi@vger.kernel.org" , "maxg@mellanox.com" , "israelr@mellanox.com" , "hare@suse.de" , "martin.petersen@oracle.com" Subject: Re: [PATCH v3 3/4] sd: Make synchronize cache upon shutdown asynchronous Thread-Topic: [PATCH v3 3/4] sd: Make synchronize cache upon shutdown asynchronous Thread-Index: AQHSt6Dnu2fwIPQi8EGD3QG5BkWsKaHLNU+AgAAUGACADMRDAA== Date: Wed, 26 Apr 2017 18:53:59 +0000 Message-ID: <1493232838.2632.9.camel@sandisk.com> References: <20170417173436.15555-1-bart.vanassche@sandisk.com> <20170417173436.15555-4-bart.vanassche@sandisk.com> <20170418144429.GA28949@bblock-ThinkPad-W530> <1492530984.3306.25.camel@HansenPartnership.com> In-Reply-To: <1492530984.3306.25.camel@HansenPartnership.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: HansenPartnership.com; dkim=none (message not signed) header.d=none; HansenPartnership.com; dmarc=none action=none header.from=sandisk.com; x-originating-ip: [63.163.107.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0401MB1535; 7:u2YC/Tnb+0CC9EPf/4MrepP7WCoLYohLzrQG9qCQap6ViQbGubqWr1wZQZhdeykSVgAuSaaXRG+Vl7/vyUgFBjMaK4zIHeEU65OrBZ+RRxbJCUzx4y1Z8uRVJDeXl8i9TBhGyHwwomv1rIAxxO6FFape+N0oOhd//xRLOkovtO29Ja9fjrdS/FfwFgX1/iJ+es0aP3pLgqQ1/aq5ZFazYkLyaqmGOS0Ozbxw2za6d0LRd3rm7n/opiOkTNTMsQu6nyyFTbnM15yq7hdgaVcm0zJdoXTA5Izlu2B4GFLRanzF05Q6ZsYJYCPofYlyiL3pNTyr425yVyGPPpQxDGgbkg==; 20:8B9/qstkN3foEelUnAPNpDtM/BSCVbvDZIwajKrOK56mM9BfnvYNrBhgqbj8YO8jxw3GMK6qDDOedazt6oCup5wfOtjU8IJ2pkxoFy91IZTj0Q+Jprp2KpAVo5ZaXYS7k0sjGj7XXysqIJbs27Z206cZT0ZK+ZRBlSNZIBN/yjs= x-ms-office365-filtering-correlation-id: 1589df7f-adcd-4e64-9749-08d48cd599ba x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR0401MB1535; wdcipoutbound: EOP-TRUE x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:CY1PR0401MB1535; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0401MB1535; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39860400002)(39450400003)(39840400002)(377424004)(24454002)(3660700001)(6436002)(5890100001)(2900100001)(3846002)(6506006)(6116002)(81166006)(8676002)(77096006)(102836003)(189998001)(2501003)(6486002)(3280700002)(2906002)(86362001)(103116003)(8936002)(122556002)(33646002)(93886004)(38730400002)(25786009)(66066001)(4326008)(36756003)(7736002)(6512007)(76176999)(54906002)(305945005)(2950100002)(99286003)(6246003)(229853002)(54356999)(50986999)(99936001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0401MB1535; H:CY1PR0401MB1536.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sandisk.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 18:53:59.8675 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1535 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 On Tue, 2017-04-18 at 08:56 -0700, James Bottomley wrote: > The priority has got to be the removal we've been ordered to do rather > than waiting around to see if the transport comes back so we can send a > final flush. > > How about this approach. It goes straight to DEL if the device is > blocked (skipping CANCEL). This means that all the commands issued in > ->shutdown will error in the mid-layer, thus making the removal proceed > without being stopped. > > James > > --- > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index e5a2d590a104..31171204cfd1 100644 > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -2611,7 +2611,6 @@ scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state) > case SDEV_QUIESCE: > case SDEV_OFFLINE: > case SDEV_TRANSPORT_OFFLINE: > - case SDEV_BLOCK: > break; > default: > goto illegal; > @@ -2625,6 +2624,7 @@ scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state) > case SDEV_OFFLINE: > case SDEV_TRANSPORT_OFFLINE: > case SDEV_CANCEL: > + case SDEV_BLOCK: > case SDEV_CREATED_BLOCK: > break; > default: > diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c > index 82dfe07b1d47..788309e307e9 100644 > --- a/drivers/scsi/scsi_sysfs.c > +++ b/drivers/scsi/scsi_sysfs.c > @@ -1282,8 +1282,14 @@ void __scsi_remove_device(struct scsi_device *sdev) > return; > > if (sdev->is_visible) { > + /* > + * If blocked, we go straight to DEL so any commands > + * issued during the driver shutdown (like sync cache) > + * are errored > + */ > if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0) > - return; > + if (scsi_device_set_state(sdev, SDEV_DEL) != 0) > + return; > > bsg_unregister_queue(sdev->request_queue); > device_unregister(&sdev->sdev_dev); > > Hello James, How about modifying the above patch by adding a mutex to avoid that the transition to SDEV_DEL and blocking the request queue happen in the wrong order, e.g. as in the attached three patches? Thanks, Bart. From f558b519922837eec5410de7aed059cb42c10b64 Mon Sep 17 00:00:00 2001 From: Bart Van Assche Date: Tue, 18 Apr 2017 10:11:02 -0700 Subject: [PATCH 3/3] Make __scsi_remove_device go straight from BLOCKED to DEL If a device is blocked, make __scsi_remove_device() cause it to transition to the DEL state. This means that all the commands issued in .shutdown() will error in the mid-layer, thus making the removal proceed without being stopped. This patch is a slightly modified version of a patch from James Bottomley. Signed-off-by: Bart Van Assche Cc: James Bottomley Cc: Israel Rukshin Cc: Max Gurtovoy Cc: Hannes Reinecke Cc: Benjamin Block --- drivers/scsi/scsi_lib.c | 2 +- drivers/scsi/scsi_sysfs.c | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 6ab7c63110b1..2e84bb85d0e6 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -2611,7 +2611,6 @@ scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state) case SDEV_QUIESCE: case SDEV_OFFLINE: case SDEV_TRANSPORT_OFFLINE: - case SDEV_BLOCK: break; default: goto illegal; @@ -2625,6 +2624,7 @@ scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state) case SDEV_OFFLINE: case SDEV_TRANSPORT_OFFLINE: case SDEV_CANCEL: + case SDEV_BLOCK: case SDEV_CREATED_BLOCK: break; default: diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index 5892cd95c546..8b9b6aaf6a9e 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -1288,7 +1288,20 @@ void __scsi_remove_device(struct scsi_device *sdev) * has finished before changing the device state. */ mutex_lock(&sdev->state_mutex); + /* + * If blocked, we go straight to DEL and restart the queue so + * any commands issued during driver shutdown (like sync + * cache) are errored immediately. + */ res = scsi_device_set_state(sdev, SDEV_CANCEL); + if (res != 0) { + res = scsi_device_set_state(sdev, SDEV_DEL); + if (res == 0) { + scsi_start_queue(sdev); + sdev_printk(KERN_DEBUG, sdev, + "Changed state from BLOCKED to DEL\n"); + } + } mutex_unlock(&sdev->state_mutex); if (res != 0) -- 2.12.2