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;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Thu, 30 Apr 2020 13:40:43 +0800
From:   Can Guo <cang@codeaurora.org>
To:     Bart Van Assche <bvanassche@acm.org>
Cc:     asutoshd@codeaurora.org, nguyenb@codeaurora.org,
        hongwus@codeaurora.org, rnayak@codeaurora.org,
        stanley.chu@mediatek.com, alim.akhtar@samsung.com,
        beanhuo@micron.com, Avri.Altman@wdc.com,
        bjorn.andersson@linaro.org, linux-scsi@vger.kernel.org,
        kernel-team@android.com, saravanak@google.com, salyzyn@google.com,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/1] scsi: pm: Balance pm_only counter of request queue
 during system resume
In-Reply-To: <9e15123e-4315-15cd-3d23-2df6144bd376@acm.org>
References: <1588219805-25794-1-git-send-email-cang@codeaurora.org>
 <9e15123e-4315-15cd-3d23-2df6144bd376@acm.org>
Message-ID: <1ef85ee212bee679f7b2927cbbc79cba@codeaurora.org>
User-Agent: Roundcube Webmail/1.3.9
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Bart,

On 2020-04-30 13:08, Bart Van Assche 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?
> 
> Thanks,
> 
> Bart.

As the issue was found after system resumes, so the issue was discovered
during system suspend/resume test, and it is very easy to be replicated.
After system resumes, if this issue hits some scsi devices, all bios 
sent
to their request queues are blocked, which may cause a system hang if 
the
scsi devices are vital to system functionality.

To make sure the patch work well, we have tested system suspend/resume
and made sure no system hang happen due to request queues got blocked
by imbalanced pm_only counter.

Thanks,

Can Guo.