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: <20201125080659.GB2532@lahna.fi.intel.com>
Date:   Wed, 25 Nov 2020 10:06:59 +0200
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     Linux ACPI <linux-acpi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux PCI <linux-pci@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Bjorn Helgaas <helgaas@...nel.org>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>
Subject: Re: [PATCH v1 1/2] PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()

On Tue, Nov 24, 2020 at 08:44:00PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> 
> The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
> be reference counted for wakeup enabling, because they may be enabled
> to signal wakeup on behalf of their subordinate devices and that
> may happen for multiple times in a row, whereas for the other devices
> it only makes sense to enable wakeup signaling once.
> 
> However, this becomes problematic if the bridge itself is suspended,
> because it is treated as a "regular" device in that case and the
> reference counting doesn't work.
> 
> For instance, suppose that there are two devices below a bridge and
> they both can signal wakeup.  Every time one of them is suspended,
> wakeup signaling is enabled for the bridge, so when they both have
> been suspended, the bridge's wakeup reference counter value is 2.
> 
> Say that the bridge is suspended subsequently and acpi_pci_wakeup()
> is called for it.  Because the bridge can signal wakeup, that
> function will invoke acpi_pm_set_device_wakeup() to configure it
> and __acpi_pm_set_device_wakeup() will be called with the last
> argument equal to 1.  This causes __acpi_device_wakeup_enable()
> invoked by it to omit the reference counting, because the reference
> counter of the target device (the bridge) is 2 at that time.
> 
> Now say that the bridge resumes and one of the device below it
> resumes too, so the bridge's reference counter becomes 0 and
> wakeup signaling is disabled for it, but there is still the other
> suspended device which may need the bridge to signal wakeup on its
> behalf and that is not going to work.
> 
> To address this scenario, use wakeup enable reference counting for
> all devices, not just for bridges, so drop the last argument from
> __acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(),
> which causes acpi_pm_set_device_wakeup() and
> acpi_pm_set_bridge_wakeup() to become identical, so drop the latter
> and use the former instead of it everywhere.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

Reviewed-by: Mika Westerberg <mika.westerberg@...ux.intel.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ