From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11998C433DF for ; Fri, 31 Jul 2020 09:27:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D536F208E4 for ; Fri, 31 Jul 2020 09:27:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="DiYFsj2l" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732876AbgGaJ1e (ORCPT ); Fri, 31 Jul 2020 05:27:34 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:65091 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1732094AbgGaJ1b (ORCPT ); Fri, 31 Jul 2020 05:27:31 -0400 X-UUID: cbbaf8822e424bddb1c75be84ac7d6c7-20200731 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=au+qktezYgw+jt5L5XG7E4RAshRFGuWcZYnfoHyoQQY=; b=DiYFsj2lfgst5j049P5VVFhtWVduxXYty6PAgtWFTp6+TIsF148sD43WcmGOEEXpltYvZgfkhhzNZ512aPm/Wigt+2oAo7Aiig8YALHB37x7oVtsa/+o4k7/8TH6BuSBM3KoH2T6cSUH/4H5Kc/WK9v3wfZm5VoiSxGe0cqFaro=; X-UUID: cbbaf8822e424bddb1c75be84ac7d6c7-20200731 Received: from mtkcas07.mediatek.inc [(172.21.101.84)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 367703745; Fri, 31 Jul 2020 17:27:25 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 17:27:21 +0800 Received: from [172.21.77.33] (172.21.77.33) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 31 Jul 2020 17:27:22 +0800 Message-ID: <1596187643.17247.62.camel@mtkswgap22> Subject: Re: [PATCH v4] scsi: ufs: Quiesce all scsi devices before shutdown From: Stanley Chu To: Can Guo CC: , , , , , , , , , , , , Kuohong Wang =?UTF-8?Q?=28=E7=8E=8B=E5=9C=8B=E9=B4=BB=29?= , Peter Wang =?UTF-8?Q?=28=E7=8E=8B=E4=BF=A1=E5=8F=8B=29?= , Chun-Hung Wu =?UTF-8?Q?=28=E5=B7=AB=E9=A7=BF=E5=AE=8F=29?= , "Andy Teng ( =?ISO-8859-1?Q?=1B$B{}G!9(=1B?= (B)" , Chaotian Jing =?UTF-8?Q?=28=E4=BA=95=E6=9C=9D=E5=A4=A9=29?= , CC Chou =?UTF-8?Q?=28=E5=91=A8=E5=BF=97=E6=9D=B0=29?= Date: Fri, 31 Jul 2020 17:27:23 +0800 In-Reply-To: <1d74498da71ba54e23cd82ee6400dbd4@codeaurora.org> References: <20200724140140.18186-1-stanley.chu@mediatek.com> <84510fc12ada0de8284e6a689b7a2358@codeaurora.org> <1596183773.17247.60.camel@mtkswgap22> <1d74498da71ba54e23cd82ee6400dbd4@codeaurora.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N Content-Transfer-Encoding: base64 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org SGkgQ2FuLA0KDQpPbiBGcmksIDIwMjAtMDctMzEgYXQgMTY6NTggKzA4MDAsIENhbiBHdW8gd3Jv dGU6DQo+IEhpIFN0YW5sZXksDQo+IA0KPiBPbiAyMDIwLTA3LTMxIDE2OjIyLCBTdGFubGV5IENo dSB3cm90ZToNCj4gPiBIaSBDYW4sDQo+ID4gDQo+ID4gT24gTW9uLCAyMDIwLTA3LTI3IGF0IDE1 OjMwICswODAwLCBDYW4gR3VvIHdyb3RlOg0KPiA+PiBIaSBTdGFubGV5LA0KPiA+PiANCj4gPj4g T24gMjAyMC0wNy0yNCAyMjowMSwgU3RhbmxleSBDaHUgd3JvdGU6DQo+ID4+ID4gQ3VycmVudGx5 IEkvTyByZXF1ZXN0IGNvdWxkIGJlIHN0aWxsIHN1Ym1pdHRlZCB0byBVRlMgZGV2aWNlIHdoaWxl DQo+ID4+ID4gVUZTIGlzIHdvcmtpbmcgb24gc2h1dGRvd24gZmxvdy4gVGhpcyBtYXkgbGVhZCB0 byByYWNpbmcgYXMgYmVsb3cNCj4gPj4gPiBzY2VuYXJpb3MgYW5kIGZpbmFsbHkgc3lzdGVtIG1h eSBjcmFzaCBkdWUgdG8gdW5jbG9ja2VkIHJlZ2lzdGVyDQo+ID4+ID4gYWNjZXNzZXMuDQo+ID4+ ID4NCj4gPj4gPiBUbyBmaXggdGhpcyBraW5kIG9mIGlzc3Vlcywgc3BlY2lmaWNhbGx5IHF1aWVz Y2UgYWxsIFNDU0kgZGV2aWNlcw0KPiA+PiA+IGJlZm9yZSBVRlMgc2h1dGRvd24gdG8gYmxvY2sg YWxsIEkvTyByZXF1ZXN0IHNlbmRpbmcgZnJvbSBibG9jaw0KPiA+PiA+IGxheWVyLg0KPiA+PiA+ DQo+ID4+ID4gRXhhbXBsZSBvZiByYWNpbmcgc2NlbmFyaW86IFdoaWxlIFVGUyBkZXZpY2UgaXMg cnVudGltZS1zdXNwZW5kZWQNCj4gPj4gPg0KPiA+PiA+IFRocmVhZCAjMTogRXhlY3V0aW5nIFVG UyBzaHV0ZG93biBmbG93LCBlLmcuLA0KPiA+PiA+ICAgICAgICAgICAgdWZzaGNkX3N1c3BlbmQo VUZTX1NIVVRET1dOX1BNKQ0KPiA+PiA+IFRocmVhZCAjMjogRXhlY3V0aW5nIHJ1bnRpbWUgcmVz dW1lIGZsb3cgdHJpZ2dlcmVkIGJ5IEkvTyByZXF1ZXN0LA0KPiA+PiA+ICAgICAgICAgICAgZS5n LiwgdWZzaGNkX3Jlc3VtZShVRlNfUlVOVElNRV9QTSkNCj4gPj4gPg0KPiA+PiANCj4gPj4gSSBk b24ndCBxdWl0ZSBnZXQgaXQsIGhvdyBjYW4geW91IHByZXZlbnQgYmxvY2sgbGF5ZXIgUE0gZnJv bSBpbmlhdGluZw0KPiA+PiBoYmEgcnVudGltZSByZXN1bWUgYnkgcXVpZXNjaW5nIHRoZSBzY3Np IGRldmljZXM/IEJsb2NrIGxheWVyIFBNDQo+ID4+IGluaWF0ZXMgaGJhIGFzeW5jIHJ1bnRpbWUg cmVzdW1lIGluIGJsa19xdWV1ZV9lbnRlcigpLiBCdXQgcXVpZXNjaW5nDQo+ID4+IHRoZSBzY3Np IGRldmljZXMgY2FuIG9ubHkgcHJldmVudCBnZW5lcmFsIEkvTyByZXF1ZXN0cyBmcm9tIHBhc3Np bmcNCj4gPj4gdGhyb3VnaCBzY3NpX3F1ZXVlX3JxKCkgY2FsbGJhY2suDQo+ID4+IA0KPiA+PiBT YXkgaGJhIGlzIHJ1bnRpbWUgc3VzcGVuZGVkLCBpZiBhbiBJL08gcmVxdWVzdCB0byBzZGEgaXMg c2VudCBmcm9tDQo+ID4+IGJsb2NrIGxheWVyIChzZGEgbXVzdCBiZSBydW50aW1lIHN1c3BlbmRl ZCBhcyB3ZWxsIGF0IHRoaXMgdGltZSksDQo+ID4+IGJsa19xdWV1ZV9lbnRlcigpIGluaXRpYXRl cyBhc3luYyBydW50aW1lIHJlc3VtZSBmb3Igc2RhLiBCdXQgc2luY2UNCj4gPj4gc2RhJ3MgcGFy ZW50cyBhcmUgYWxzbyBydW50aW1lIHN1c3BlbmRlZCwgdGhlIFJQTSBmcmFtZXdvcmsgc2hhbGwg ZG8NCj4gPj4gcnVudGltZSByZXN1bWUgdG8gdGhlIGRldmljZXMgaW4gdGhlIHNlcXVlbmNlIGhi YS0+aG9zdC0+dGFyZ2V0LT5zZGEuDQo+ID4+IEluIHRoaXMgY2FzZSwgdWZzaGNkX3Jlc3VtZSgp IHN0aWxsIHJ1bnMgY29uY3VycmVudGx5LCBubz8NCj4gPj4gDQo+ID4gDQo+ID4gWW91IGFyZSBy aWdodC4gVGhpcyBwYXRjaCBjYW4gbm90IGZpeCB0aGUgY2FzZSB5b3UgbWVudGlvbmVkLiBJdCBq dXN0DQo+ID4gcHJldmVudHMgImdlbmVyYWwgSS9PIHJlcXVlc3RzIi4NCj4gPiANCj4gPiBTbyBw ZXJoYXBzIHdlIGFsc28gbmVlZCBiZWxvdyBwYXRjaD8NCj4gPiANCj4gPiAjMiBzY3NpOiB1ZnM6 IFVzZSBwbV9ydW50aW1lX2dldF9zeW5jIGluIHNodXRkb3duIGZsb3cNCj4gPiBodHRwczovL3Bh dGNod29yay5rZXJuZWwub3JnL3BhdGNoLzEwOTY0MDk3Lw0KPiANCj4gVGhhdCBpcyB3aGF0IEkg YW0gdGFsa2luZyBhYm91dCwgd2UgZGVmaW5pdGVseSBuZWVkIHRoaXMuIFNpbmNlDQo+IHlvdSBh cmUgYWxyZWFkeSB3b3JraW5nIG9uIHRoZSBmaXhlcyB0byB0aGUgc2h1dGRvd24gcGF0aCwgSSB3 aWxsDQo+IG5vdCB1cGxvYWQgbXkgZml4ZXMgKGJhc2ljYWxseSBsb29rIHNhbWUgd2l0aCB5b3Vy cykuIEhvd2V2ZXIsIGFzDQo+IHJlZ2FyZCBmb3IgdGhlIG5ldyBjaGFuZ2UsIGlmIHBtX3J1bnRp bWVfZ2V0X3N5bmMoaGJhLT5kZXYpIDwgMCwNCj4gaGJhIGNhbiBzdGlsbCBiZSBydW50aW1lIEFD VElWRSwgd2h5IGRpcmVjdGx5IGdvdG8gb3V0IHdpdGhvdXQgYQ0KPiBjaGVjayBvZiBoYmEncyBy dW50aW1lIHN0YXR1cz8NCj4gDQoNClRoYW5rcyBmb3IgcmVtaW5kaW5nIHRoaXMuIFRoZW4gSSB3 aWxsIGZpeCBpdCBhbmQgcmVzZW5kIGJvdGggcGF0Y2hlcyBhcw0KYSBuZXcgc2VyaWVzIHRvIGZp eCB0aGUgc2h1dGRvd24gcGF0aC4NCg0KVGhhbmtzIHNvIG11Y2gsDQpTdGFubGV5IENodQ0KDQoN Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C449C433E0 for ; Fri, 31 Jul 2020 09:37:47 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DAE9520829 for ; Fri, 31 Jul 2020 09:37:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Nflinr/2"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="DiYFsj2l" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DAE9520829 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Date:To:From: Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9xdpn/MuAffiTdwJ/o87KYVZxaRnSSY4bDVX/PwuIio=; b=Nflinr/2P8hzG7oGBNQOt8KJS LZ2PfvyvSap+v6EdN/CU1dScncsMiYxn3bcnFYSyelcDS+L3Kng3IrH8FLpS0d6+TvUzDJ+10+I3V lHgqjYFkQ5lrlrDI9lC1KBw2/HFTb/gLjaj4bVVk+Ea5+FR6n/Zgvbu3wkxEMnWAqqN+u62YrCcLe 5DJqEY/cmFavl4fe4RfRlvPAjNrJlZiOE1TRfKtVH4m5AhjY7nD2XLsoR0uPuPWXy++a9G/1VQutD K4IYkcIxa5wFwNaVxgxxY2n249hbxKco1nU/jWZbuGp3c0I3cuAaEJdwj+aQYylHwBOV4WujjG3xa Z33KbbRYQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1RTt-0001kW-Qs; Fri, 31 Jul 2020 09:37:37 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1RTo-0001j0-BJ; Fri, 31 Jul 2020 09:37:34 +0000 X-UUID: 576c44c7a3374af5a1ef97136a9571a3-20200731 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=au+qktezYgw+jt5L5XG7E4RAshRFGuWcZYnfoHyoQQY=; b=DiYFsj2lfgst5j049P5VVFhtWVduxXYty6PAgtWFTp6+TIsF148sD43WcmGOEEXpltYvZgfkhhzNZ512aPm/Wigt+2oAo7Aiig8YALHB37x7oVtsa/+o4k7/8TH6BuSBM3KoH2T6cSUH/4H5Kc/WK9v3wfZm5VoiSxGe0cqFaro=; X-UUID: 576c44c7a3374af5a1ef97136a9571a3-20200731 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 447678340; Fri, 31 Jul 2020 01:37:13 -0800 Received: from MTKMBS02N1.mediatek.inc (172.21.101.77) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 02:27:24 -0700 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 17:27:21 +0800 Received: from [172.21.77.33] (172.21.77.33) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 31 Jul 2020 17:27:22 +0800 Message-ID: <1596187643.17247.62.camel@mtkswgap22> Subject: Re: [PATCH v4] scsi: ufs: Quiesce all scsi devices before shutdown From: Stanley Chu To: Can Guo Date: Fri, 31 Jul 2020 17:27:23 +0800 In-Reply-To: <1d74498da71ba54e23cd82ee6400dbd4@codeaurora.org> References: <20200724140140.18186-1-stanley.chu@mediatek.com> <84510fc12ada0de8284e6a689b7a2358@codeaurora.org> <1596183773.17247.60.camel@mtkswgap22> <1d74498da71ba54e23cd82ee6400dbd4@codeaurora.org> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200731_053732_740057_E47463E7 X-CRM114-Status: GOOD ( 23.54 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-scsi@vger.kernel.org, martin.petersen@oracle.com, "Andy Teng \($B{}G!9\( \(B\)" , jejb@linux.ibm.com, Chun-Hung Wu =?UTF-8?Q?=28=E5=B7=AB=E9=A7=BF=E5=AE=8F=29?= , Kuohong Wang =?UTF-8?Q?=28=E7=8E=8B=E5=9C=8B=E9=B4=BB=29?= , linux-kernel@vger.kernel.org, asutoshd@codeaurora.org, avri.altman@wdc.com, linux-mediatek@lists.infradead.org, Peter Wang =?UTF-8?Q?=28=E7=8E=8B=E4=BF=A1=E5=8F=8B=29?= , alim.akhtar@samsung.com, matthias.bgg@gmail.com, beanhuo@micron.com, Chaotian Jing =?UTF-8?Q?=28=E4=BA=95=E6=9C=9D=E5=A4=A9=29?= , CC Chou =?UTF-8?Q?=28=E5=91=A8=E5=BF=97=E6=9D=B0=29?= , linux-arm-kernel@lists.infradead.org, bvanassche@acm.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Hi Can, On Fri, 2020-07-31 at 16:58 +0800, Can Guo wrote: > Hi Stanley, > > On 2020-07-31 16:22, Stanley Chu wrote: > > Hi Can, > > > > On Mon, 2020-07-27 at 15:30 +0800, Can Guo wrote: > >> Hi Stanley, > >> > >> On 2020-07-24 22:01, Stanley Chu wrote: > >> > Currently I/O request could be still submitted to UFS device while > >> > UFS is working on shutdown flow. This may lead to racing as below > >> > scenarios and finally system may crash due to unclocked register > >> > accesses. > >> > > >> > To fix this kind of issues, specifically quiesce all SCSI devices > >> > before UFS shutdown to block all I/O request sending from block > >> > layer. > >> > > >> > Example of racing scenario: While UFS device is runtime-suspended > >> > > >> > Thread #1: Executing UFS shutdown flow, e.g., > >> > ufshcd_suspend(UFS_SHUTDOWN_PM) > >> > Thread #2: Executing runtime resume flow triggered by I/O request, > >> > e.g., ufshcd_resume(UFS_RUNTIME_PM) > >> > > >> > >> I don't quite get it, how can you prevent block layer PM from iniating > >> hba runtime resume by quiescing the scsi devices? Block layer PM > >> iniates hba async runtime resume in blk_queue_enter(). But quiescing > >> the scsi devices can only prevent general I/O requests from passing > >> through scsi_queue_rq() callback. > >> > >> Say hba is runtime suspended, if an I/O request to sda is sent from > >> block layer (sda must be runtime suspended as well at this time), > >> blk_queue_enter() initiates async runtime resume for sda. But since > >> sda's parents are also runtime suspended, the RPM framework shall do > >> runtime resume to the devices in the sequence hba->host->target->sda. > >> In this case, ufshcd_resume() still runs concurrently, no? > >> > > > > You are right. This patch can not fix the case you mentioned. It just > > prevents "general I/O requests". > > > > So perhaps we also need below patch? > > > > #2 scsi: ufs: Use pm_runtime_get_sync in shutdown flow > > https://patchwork.kernel.org/patch/10964097/ > > That is what I am talking about, we definitely need this. Since > you are already working on the fixes to the shutdown path, I will > not upload my fixes (basically look same with yours). However, as > regard for the new change, if pm_runtime_get_sync(hba->dev) < 0, > hba can still be runtime ACTIVE, why directly goto out without a > check of hba's runtime status? > Thanks for reminding this. Then I will fix it and resend both patches as a new series to fix the shutdown path. Thanks so much, Stanley Chu _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73033C433E0 for ; Fri, 31 Jul 2020 09:39:16 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 403E520829 for ; Fri, 31 Jul 2020 09:39:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="G6PIx+f8"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="DiYFsj2l" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 403E520829 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Date:To:From: Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=dGh2wPsimcMA8jnqtZ9DndDuMbBE7N+9iVqaBI9q8T4=; b=G6PIx+f8JgOZtn5heSt15u/D7 JSHtbxQhcmj7Vt8bJlHUJz5NBT91oEmK4tfVSaJWYjQawdx26B1FOPEIpD9UMGaHZutuL/moOxKPf QAM5iKGmPHFinW1b9adLcDLDWnnqiT9P/Bj9gSjhtlCCk6PnJ8w3m+uPsM2yHghC/bF+GTh4mSe1x J5bpfaTfRAbSb4UQCLF9sUxSvnVnmc/QS0Oi3xbNLmoUFj2IpVG6/qmodxdPWb14raTkOLSOfhAYl 7ekbKswNtDYxE8D59zXGDIeZ6g1FNtpHAgRlBZizW1v7AelEdFn4dX82vSC3UHabsBeWhGxb+NEQP bNMN+jvmw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1RTr-0001jj-Vs; Fri, 31 Jul 2020 09:37:36 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1RTo-0001j0-BJ; Fri, 31 Jul 2020 09:37:34 +0000 X-UUID: 576c44c7a3374af5a1ef97136a9571a3-20200731 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=au+qktezYgw+jt5L5XG7E4RAshRFGuWcZYnfoHyoQQY=; b=DiYFsj2lfgst5j049P5VVFhtWVduxXYty6PAgtWFTp6+TIsF148sD43WcmGOEEXpltYvZgfkhhzNZ512aPm/Wigt+2oAo7Aiig8YALHB37x7oVtsa/+o4k7/8TH6BuSBM3KoH2T6cSUH/4H5Kc/WK9v3wfZm5VoiSxGe0cqFaro=; X-UUID: 576c44c7a3374af5a1ef97136a9571a3-20200731 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 447678340; Fri, 31 Jul 2020 01:37:13 -0800 Received: from MTKMBS02N1.mediatek.inc (172.21.101.77) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 02:27:24 -0700 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 17:27:21 +0800 Received: from [172.21.77.33] (172.21.77.33) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 31 Jul 2020 17:27:22 +0800 Message-ID: <1596187643.17247.62.camel@mtkswgap22> Subject: Re: [PATCH v4] scsi: ufs: Quiesce all scsi devices before shutdown From: Stanley Chu To: Can Guo Date: Fri, 31 Jul 2020 17:27:23 +0800 In-Reply-To: <1d74498da71ba54e23cd82ee6400dbd4@codeaurora.org> References: <20200724140140.18186-1-stanley.chu@mediatek.com> <84510fc12ada0de8284e6a689b7a2358@codeaurora.org> <1596183773.17247.60.camel@mtkswgap22> <1d74498da71ba54e23cd82ee6400dbd4@codeaurora.org> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200731_053732_740057_E47463E7 X-CRM114-Status: GOOD ( 23.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-scsi@vger.kernel.org, martin.petersen@oracle.com, "Andy Teng \($B{}G!9\( \(B\)" , jejb@linux.ibm.com, Chun-Hung Wu =?UTF-8?Q?=28=E5=B7=AB=E9=A7=BF=E5=AE=8F=29?= , Kuohong Wang =?UTF-8?Q?=28=E7=8E=8B=E5=9C=8B=E9=B4=BB=29?= , linux-kernel@vger.kernel.org, asutoshd@codeaurora.org, avri.altman@wdc.com, linux-mediatek@lists.infradead.org, Peter Wang =?UTF-8?Q?=28=E7=8E=8B=E4=BF=A1=E5=8F=8B=29?= , alim.akhtar@samsung.com, matthias.bgg@gmail.com, beanhuo@micron.com, Chaotian Jing =?UTF-8?Q?=28=E4=BA=95=E6=9C=9D=E5=A4=A9=29?= , CC Chou =?UTF-8?Q?=28=E5=91=A8=E5=BF=97=E6=9D=B0=29?= , linux-arm-kernel@lists.infradead.org, bvanassche@acm.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Can, On Fri, 2020-07-31 at 16:58 +0800, Can Guo wrote: > Hi Stanley, > > On 2020-07-31 16:22, Stanley Chu wrote: > > Hi Can, > > > > On Mon, 2020-07-27 at 15:30 +0800, Can Guo wrote: > >> Hi Stanley, > >> > >> On 2020-07-24 22:01, Stanley Chu wrote: > >> > Currently I/O request could be still submitted to UFS device while > >> > UFS is working on shutdown flow. This may lead to racing as below > >> > scenarios and finally system may crash due to unclocked register > >> > accesses. > >> > > >> > To fix this kind of issues, specifically quiesce all SCSI devices > >> > before UFS shutdown to block all I/O request sending from block > >> > layer. > >> > > >> > Example of racing scenario: While UFS device is runtime-suspended > >> > > >> > Thread #1: Executing UFS shutdown flow, e.g., > >> > ufshcd_suspend(UFS_SHUTDOWN_PM) > >> > Thread #2: Executing runtime resume flow triggered by I/O request, > >> > e.g., ufshcd_resume(UFS_RUNTIME_PM) > >> > > >> > >> I don't quite get it, how can you prevent block layer PM from iniating > >> hba runtime resume by quiescing the scsi devices? Block layer PM > >> iniates hba async runtime resume in blk_queue_enter(). But quiescing > >> the scsi devices can only prevent general I/O requests from passing > >> through scsi_queue_rq() callback. > >> > >> Say hba is runtime suspended, if an I/O request to sda is sent from > >> block layer (sda must be runtime suspended as well at this time), > >> blk_queue_enter() initiates async runtime resume for sda. But since > >> sda's parents are also runtime suspended, the RPM framework shall do > >> runtime resume to the devices in the sequence hba->host->target->sda. > >> In this case, ufshcd_resume() still runs concurrently, no? > >> > > > > You are right. This patch can not fix the case you mentioned. It just > > prevents "general I/O requests". > > > > So perhaps we also need below patch? > > > > #2 scsi: ufs: Use pm_runtime_get_sync in shutdown flow > > https://patchwork.kernel.org/patch/10964097/ > > That is what I am talking about, we definitely need this. Since > you are already working on the fixes to the shutdown path, I will > not upload my fixes (basically look same with yours). However, as > regard for the new change, if pm_runtime_get_sync(hba->dev) < 0, > hba can still be runtime ACTIVE, why directly goto out without a > check of hba's runtime status? > Thanks for reminding this. Then I will fix it and resend both patches as a new series to fix the shutdown path. Thanks so much, Stanley Chu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel