linux-kernel - Re: [PATCH] PM: sleep: core: Fix the handling of pending runtime resume requests

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]

Message-ID: <2486532.D7zGhtygOF@kreacher>
Date:   Mon, 24 Aug 2020 15:38:39 +0200
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     Alan Stern <stern@...land.harvard.edu>,
        Linux PM <linux-pm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH] PM: sleep: core: Fix the handling of pending runtime resume requests

On Monday, August 24, 2020 10:34:52 AM CEST Mika Westerberg wrote:
> Hi,
> 
> On Fri, Aug 21, 2020 at 03:34:42PM -0400, Alan Stern wrote:
> > This means that the code could be simplified to just:
> > 
> > 	pm_runtime_barrier(dev);
> > 
> > Will this fix the reported bug?  It seems likely to me that the actual 
> > problem with the failure scenario in the patch description was that 
> > turning on an ACPI power resource causes runtime-resume requests to be 
> > queued for all devices sharing that resource.  Wouldn't it make more 
> > sense to resume only the device that requested it and leave the others 
> > in runtime suspend?
> 
> The problem with at least PCIe devices that share ACPI power resources
> is that once you turn on the power resource all the devices that shared
> it will go into D0uninitialized power state and that means they lose all
> wake configuration etc. so they need to be re-initialized by their
> driver before they can go back to D3(cold) in order for their wakes to
> still work.

Plus devices in D0uninitialized may prevent the SoC from allowing package
C-states to be used for the processor AFAICS.

BTW, does the patch make the issue at hand go away?