Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1791446ybz; Thu, 30 Apr 2020 05:41:09 -0700 (PDT) X-Google-Smtp-Source: APiQypLnJj+I7jmVVXDPvy//arcmio7vBXE2TdOuZGah6R3vyMAM4evxZ0BYyTHAf0fnZ/yLe8lC X-Received: by 2002:aa7:de0b:: with SMTP id h11mr2492411edv.133.1588250469049; Thu, 30 Apr 2020 05:41:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588250469; cv=none; d=google.com; s=arc-20160816; b=T4eYanBLq48haOYjsitJWaDfK9EZ8QJ18WKOgT6JpoEgL+/txHyTdMMNva6+T3qYP5 5JNO9ZNSCRGcUTmljat26QQkcPS3Cra9hxRyKTCPFdJYisnhcJLBZuRFju80kQ7+eZMK kKv8tP0om1dOBLA0az74lVYx8bDhNz7OXwoKCm4OzKYeYvtdcp9R+Dltcsg+HLu4ZxWO /1gQumfu0L7vJRHryhrIXYitMhp/PXdDfan/NaDgf8LnoGPrzlsLvUdVLhR1wsKHd1AY dxiVU6yJsdWursHRasLhEr559l6h0ptwrFqxqnkl0tFto2rSyt5+CkXIDjUTlKgZq3Rh 7G4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature; bh=s9tiGzSDMy7NhyUbB2bWUK71xrktfp/JVsuI2n9mC8A=; b=T/HgC2li+R0uKEuEmXldmPySVc+pWRVN2NjsLi1hi27iZVFDH5cavjh78+23Nnsj5D 5xI/zbZWSIoS0uFHhXkjM08xlvmYvo5+oGdjSW3jM8NHINP060Y6mf+CL5lIOX0LGmxh 5rrOIv9tLyP4Ipenh8okpNmgipz02BFGLgDf1gbjShHhyDDx5rGoQpFNefYrZX3df9Gn C+Ktl0ef+ojUgTOtuUaffPFnU7Azp8Rz3QnyCjvlB5iNlqXz97KdFa3gD63UtstHp8Cn pahtMumc8WURfHYDoceDOIaXImjhFpF6P29SlL6DVQu6Dllla6FEw6JyqF83HoaV5+06 q+mA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=u7CR8FQp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u1si5431621edf.299.2020.04.30.05.40.46; Thu, 30 Apr 2020 05:41:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=u7CR8FQp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726926AbgD3Mid (ORCPT + 99 others); Thu, 30 Apr 2020 08:38:33 -0400 Received: from mail26.static.mailgun.info ([104.130.122.26]:44506 "EHLO mail26.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726511AbgD3Mic (ORCPT ); Thu, 30 Apr 2020 08:38:32 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1588250312; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=s9tiGzSDMy7NhyUbB2bWUK71xrktfp/JVsuI2n9mC8A=; b=u7CR8FQpVednGb+38mOkq20bHa0egUVVxKoD9Xdp6O/pIsvCU/0pX9qlF0KNXgaQJAh6UQkG PDznMJ7yJqepB6vbeBgnyn3k9SJSahzrZMfDPN/sGlV84Is9OxeXW5G0KThixrIkWB9F8HFr Ui+ywX4uOFK5QSks+JjdEbGHPQE= X-Mailgun-Sending-Ip: 104.130.122.26 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5eaac6ba.7fdc60f4d570-smtp-out-n05; Thu, 30 Apr 2020 12:38:18 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id BB9F4C4478F; Thu, 30 Apr 2020 12:38:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cang) by smtp.codeaurora.org (Postfix) with ESMTPSA id EBE81C433D2; Thu, 30 Apr 2020 12:38:17 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 30 Apr 2020 20:38:17 +0800 From: Can Guo To: Avri Altman Cc: Bart Van Assche , asutoshd@codeaurora.org, nguyenb@codeaurora.org, hongwus@codeaurora.org, rnayak@codeaurora.org, stanley.chu@mediatek.com, alim.akhtar@samsung.com, beanhuo@micron.com, bjorn.andersson@linaro.org, linux-scsi@vger.kernel.org, kernel-team@android.com, saravanak@google.com, salyzyn@google.com, "James E.J. Bottomley" , "Martin K. Petersen" , open list Subject: Re: [PATCH v3 1/1] scsi: pm: Balance pm_only counter of request queue during system resume In-Reply-To: References: <1588219805-25794-1-git-send-email-cang@codeaurora.org> <9e15123e-4315-15cd-3d23-2df6144bd376@acm.org> Message-ID: X-Sender: cang@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Avri, On 2020-04-30 17:11, Avri Altman wrote: >> >> On 2020-04-29 21:10, Can Guo wrote: >> > During system resume, scsi_resume_device() decreases a request queue's >> > pm_only counter if the scsi device was quiesced before. But after that, >> > if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is >> > still held (non-zero). Current scsi resume hook only sets the RPM status >> > of the scsi device and its request queue to RPM_ACTIVE, but leaves the >> > pm_only counter unchanged. This may make the request queue's pm_only >> > counter remain non-zero after resume hook returns, hence those who are >> > waiting on the mq_freeze_wq would never be woken up. Fix this by calling >> > blk_post_runtime_resume() if pm_only is non-zero to balance the pm_only >> > counter which is held by the scsi device's RPM ops. >> >> How was this issue discovered? How has this patch been tested? > > I think this insight was originally gained as part of commit > fb276f770118 > (scsi: ufs: Enable block layer runtime PM for well-known logical units) > > But I will let Can reply on that. > > Thanks, > Avri > Thanks for pointing to that commit, but this is a different story here. SCSI devices, which have block layer runtime PM enabled, can hit this issue during system resume. In the contratry, those which have block layer runtime PM disabled are immune to this issue. Thanks, Can Guo. >> >> Thanks, >> >> Bart.