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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=ham 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 84151C43387 for ; Thu, 3 Jan 2019 09:06:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5A9D220815 for ; Thu, 3 Jan 2019 09:06:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729811AbfACJG3 (ORCPT ); Thu, 3 Jan 2019 04:06:29 -0500 Received: from mailgw01.mediatek.com ([210.61.82.183]:30034 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1728546AbfACJG3 (ORCPT ); Thu, 3 Jan 2019 04:06:29 -0500 X-UUID: bc7c53b411614b8ca164df74685d3d16-20190103 X-UUID: bc7c53b411614b8ca164df74685d3d16-20190103 Received: from mtkcas07.mediatek.inc [(172.21.101.84)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1929244374; Thu, 03 Jan 2019 17:06:22 +0800 Received: from mtkcas09.mediatek.inc (172.21.101.178) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 3 Jan 2019 17:06:21 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas09.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Thu, 3 Jan 2019 17:06:21 +0800 Message-ID: <1546506381.20657.15.camel@mtkswgap22> Subject: Re: [PATCH v2 1/1] scsi: Synchronize request queue PM status only on successful resume From: Stanley Chu To: Mika Westerberg CC: , , , , , , Date: Thu, 3 Jan 2019 17:06:21 +0800 In-Reply-To: <20190103082333.GL2469@lahna.fi.intel.com> References: <1546498395-4184-1-git-send-email-stanley.chu@mediatek.com> <1546498395-4184-3-git-send-email-stanley.chu@mediatek.com> <20190103082333.GL2469@lahna.fi.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-TM-SNTS-SMTP: ABDBEEAA6A7646D7A786FF1A6D6F3631836B44DD8F9E3D4A743B2B22AB1604AC2000:8 X-MTK: N Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Hi Mika, On Thu, 2019-01-03 at 10:23 +0200, Mika Westerberg wrote: > Hi, > > On Thu, Jan 03, 2019 at 02:53:15PM +0800, stanley.chu@mediatek.com wrote: > > From: Stanley Chu > > > > The commit 356fd2663cff ("scsi: Set request queue runtime PM status > > back to active on resume") fixed up the inconsistent RPM status between > > request queue and device. However changing request queue RPM status > > shall be done only on successful resume, otherwise status may be still > > inconsistent as below, > > > > Request queue: RPM_ACTIVE > > Device: RPM_SUSPENDED > > > > This ends up soft lockup because requests can be submitted to > > underlying devices but those devices and their required resource > > are not resumed. > > It would be good to add some example of the soft lockup you are seeing > here. Thanks for remind, I will add below example in commit message in v3. For example, After above inconsistent status happens, IO request can be submitted to UFS device driver but required resource (like clock) is not resumed yet thus lead to warning as below call stack, WARN_ON(hba->clk_gating.state != CLKS_ON); ufshcd_queuecommand scsi_dispatch_cmd scsi_request_fn __blk_run_queue cfq_insert_request __elv_add_request blk_flush_plug_list blk_finish_plug jbd2_journal_commit_transaction kjournald2 We may see all behind IO requests hang because of no response from storage host or device and then soft lockup happens in system. In the end, system may crash in many ways. > > > Fixes: 356fd2663cff ("scsi: Set request queue runtime PM status > > back to active on resume") > > You don't need to wrap this. OK! Will fix it. > > The change itself looks fine. Thanks. Stanley > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek