From patchwork Tue Apr 18 23:47:16 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: 9686701 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 43C96602C2 for ; Tue, 18 Apr 2017 23:47:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 29E33204BA for ; Tue, 18 Apr 2017 23:47:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1DE542094F; Tue, 18 Apr 2017 23:47:24 +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 44A6D204BA for ; Tue, 18 Apr 2017 23:47:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758385AbdDRXrV (ORCPT ); Tue, 18 Apr 2017 19:47:21 -0400 Received: from esa2.hgst.iphmx.com ([68.232.143.124]:64730 "EHLO esa2.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758382AbdDRXrU (ORCPT ); Tue, 18 Apr 2017 19:47:20 -0400 X-IronPort-AV: E=Sophos;i="5.37,219,1488816000"; d="scan'208,223";a="107959453" Received: from mail-dm3nam03lp0024.outbound.protection.outlook.com (HELO NAM03-DM3-obe.outbound.protection.outlook.com) ([207.46.163.24]) by ob1.hgst.iphmx.com with ESMTP; 19 Apr 2017 07:54:45 +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=hGqouVijZTMELMMVFKz+qEPTxjtavWPOzWeuWG8k7ME=; b=YCYrRbu4gQSj+Sw93NNlUonBnFLFi/T2tXmqR3SdPmamaeZxcmsT13HcdE3P+YpKFh4QneNPeJvb+3VRhlpCmyiXb1NzKAxqBoIZ0M49V6qrDpyPn8HIXPW2gXJVp5FVxme98If0nNJHFofK/D6tKIj6CMM8TfZHkXY2qNx2JGQ= 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.1034.10; Tue, 18 Apr 2017 23:47:17 +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.1034.015; Tue, 18 Apr 2017 23:47:17 +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+AgAAUGACAAIONgA== Date: Tue, 18 Apr 2017 23:47:16 +0000 Message-ID: <1492559235.2689.27.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:/C13OD7TTWhX/xhVAljwX2JR7Drrj6osU/B5/+lWR15UuTrUbuX0CuxvA3/lqbG4Qc0rgHo3yLX508LuOPiJ+u/4hF5ppWI5kaigj2qBe1mRo6/83042wHn6a+hGqxqgxbw0nzgxQhcQtlmmVfPAfisZ5ZQLe/t9NiJraMbuScAAGtHGYrIXs9BE5DQU6oG80VIIbLORa/TxEY43rgVu5iZrYzXCy5ScR3IQNwkAyZa0ESa2FvBzyKYUbo15lcadKwOVj2TMtKYTUx1YgtHOXlIAJGQfwucjIXIrHb/FhRqRKq0GOpxW2hF3yEfVC+LM6U9WZ+yHJ/SRVWpQZtEEkg==; 20:XYYIfImVbLF8ObWY7EWt2YH7IhX3qJAuJ4m+ds4z40774/X3/BpcGr4icAI70BVO+3zJhOTC/UxPeDytOVPjfhzNGVWyIQr6pB3QzpPqhG2jhMDvn6cAyGI1Q20WsIpanCyxcxNkJZSNQ5D4kKs5v+NpnMF4xcjuwgvI6YDA1iQ= x-ms-office365-filtering-correlation-id: d93be9b8-ec99-4061-9d59-08d486b53f08 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)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:CY1PR0401MB1535; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0401MB1535; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39400400002)(39860400002)(377424004)(24454002)(189998001)(5660300001)(2501003)(93886004)(77096006)(6486002)(3660700001)(305945005)(54906002)(33646002)(3280700002)(53936002)(6512007)(99286003)(5890100001)(6436002)(66066001)(6506006)(122556002)(2906002)(7736002)(2900100001)(86362001)(2950100002)(36756003)(38730400002)(8676002)(25786009)(3846002)(102836003)(6116002)(6246003)(99936001)(81166006)(4326008)(54356999)(76176999)(8936002)(50986999)(103116003); 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: 18 Apr 2017 23:47:16.9192 (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: > 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. Hello James, The three attached patches pass my tests. Please let me know how you would like to proceed with patch 1/3. Would you like to submit it yourself or is it OK for you if I mention you as author and add your Signed-off-by? Thanks, Bart. From c383551a721d30d897d45244acd331ff0af94656 Mon Sep 17 00:00:00 2001 From: Bart Van Assche Date: Tue, 28 Mar 2017 14:00:25 -0700 Subject: [PATCH 3/3] Avoid that __scsi_remove_device() hangs Since scsi_target_unblock() uses starget_for_each_device(), since starget_for_each_device() uses scsi_device_get(), since scsi_device_get() fails after unloading of the LLD kernel module has been started scsi_target_unblock() may skip devices that were affected by scsi_target_block(). Ensure that __scsi_remove_device() does not hang for blocked SCSI devices. This patch avoids that unloading the ib_srp kernel module can trigger the following hang: Call Trace: schedule+0x35/0x80 schedule_timeout+0x237/0x2d0 io_schedule_timeout+0xa6/0x110 wait_for_completion_io+0xa3/0x110 blk_execute_rq+0xdf/0x120 scsi_execute+0xce/0x150 [scsi_mod] scsi_execute_req_flags+0x8f/0xf0 [scsi_mod] sd_sync_cache+0xa9/0x190 [sd_mod] sd_shutdown+0x6a/0x100 [sd_mod] sd_remove+0x64/0xc0 [sd_mod] __device_release_driver+0x8d/0x120 device_release_driver+0x1e/0x30 bus_remove_device+0xf9/0x170 device_del+0x127/0x240 __scsi_remove_device+0xc1/0xd0 [scsi_mod] scsi_forget_host+0x57/0x60 [scsi_mod] scsi_remove_host+0x72/0x110 [scsi_mod] srp_remove_work+0x8b/0x200 [ib_srp] Reported-by: Israel Rukshin Signed-off-by: Bart Van Assche Cc: Max Gurtovoy Cc: Hannes Reinecke Cc: Benjamin Block --- drivers/scsi/scsi_sysfs.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index f95d191ec809..e9e80241ab5e 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -1309,6 +1309,15 @@ void __scsi_remove_device(struct scsi_device *sdev) * device. */ scsi_device_set_state(sdev, SDEV_DEL); + /* + * Since scsi_target_unblock() is a no-op after unloading of the SCSI + * LLD has started, explicitly restart the queue. Do this after the + * device state has been changed into SDEV_DEL because + * scsi_prep_state_check() returns BLKPREP_KILL for the SDEV_DEL state + * Do this before calling blk_cleanup_queue() to avoid that that + * function encounters a stopped queue. + */ + scsi_start_queue(sdev); blk_cleanup_queue(sdev->request_queue); cancel_work_sync(&sdev->requeue_work); -- 2.12.2