linux-kernel - Re: [PATCH v3 1/1] scsi: pm: Balance pm_only counter of request queue during system resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Apr 2020 20:38:17 +0800
From:   Can Guo <cang@...eaurora.org>
To:     Avri Altman <Avri.Altman@....com>
Cc:     Bart Van Assche <bvanassche@....org>, asutoshd@...eaurora.org,
        nguyenb@...eaurora.org, hongwus@...eaurora.org,
        rnayak@...eaurora.org, stanley.chu@...iatek.com,
        alim.akhtar@...sung.com, beanhuo@...ron.com,
        bjorn.andersson@...aro.org, linux-scsi@...r.kernel.org,
        kernel-team@...roid.com, saravanak@...gle.com, salyzyn@...gle.com,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/1] scsi: pm: Balance pm_only counter of request queue
 during system resume

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.