From: Bjorn Helgaas <helgaas@kernel.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: Laurent Bigonville <bigon@bigon.be>,
Mario Limonciello <mario.limonciello@amd.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Mika Westerberg <westeri@kernel.org>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI/ACPI: Fix runtime PM ref imbalance on hot-plug capable ports
Date: Tue, 24 Jun 2025 09:24:07 -0500 [thread overview]
Message-ID: <20250624142407.GA1473261@bhelgaas> (raw)
In-Reply-To: <86c3bd52bda4552d63ffb48f8a30343167e85271.1750698221.git.lukas@wunner.de>
On Mon, Jun 23, 2025 at 07:08:20PM +0200, Lukas Wunner wrote:
> pcie_portdrv_probe() and pcie_portdrv_remove() both call
> pci_bridge_d3_possible() to determine whether to use runtime power
> management. The underlying assumption is that pci_bridge_d3_possible()
> always returns the same value because otherwise a runtime PM reference
> imbalance occurs.
>
> That assumption falls apart if the device is inaccessible on ->remove()
> due to hot-unplug: pci_bridge_d3_possible() calls pciehp_is_native(),
> which accesses Config Space to determine whether the device is Hot-Plug
> Capable. An inaccessible device returns "all ones", which is converted
> to "all zeroes" by pcie_capability_read_dword(). Hence the device no
> longer seems Hot-Plug Capable on ->remove() even though it was on
> ->probe().
This is pretty subtle; thanks for chasing it down.
It doesn't look like anything in pci_bridge_d3_possible() should
change over the life of the device, although acpi_pci_bridge_d3() is
non-trivial.
Should we consider calling pci_bridge_d3_possible() only once and
caching the result? We already call it in pci_pm_init() and save the
result in dev->bridge_d3. That member can be changed by
pci_bridge_d3_update(), but we could add another copy that we never
update after pci_pm_init().
I worry a little that the fix is equally subtle and we could easily
reintroduce this issue with future code reorganization.
> The resulting runtime PM ref imbalance causes errors such as:
>
> pcieport 0000:02:04.0: Runtime PM usage count underflow!
>
> The Hot-Plug Capable bit is cached in pci_dev->is_hotplug_bridge.
> pci_bridge_d3_possible() only calls pciehp_is_native() if that flag is
> set. Re-checking the bit in pciehp_is_native() is thus unnecessary.
>
> However pciehp_is_native() is also called from hotplug_is_native(). Move
> the Config Space access to that function. The function is only invoked
> from acpiphp_glue.c, so move it there instead of keeping it in a publicly
> visible header.
>
> Fixes: 5352a44a561d ("PCI: pciehp: Make pciehp_is_native() stricter")
> Reported-by: Laurent Bigonville <bigon@bigon.be>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220216
> Reported-by: Mario Limonciello <mario.limonciello@amd.com>
> Closes: https://lore.kernel.org/r/20250609020223.269407-3-superm1@kernel.org/
> Link: https://lore.kernel.org/all/20250620025535.3425049-3-superm1@kernel.org/T/#u
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: stable@vger.kernel.org # v4.18+
> ---
> drivers/pci/hotplug/acpiphp_glue.c | 15 +++++++++++++++
> drivers/pci/pci-acpi.c | 5 -----
> include/linux/pci_hotplug.h | 4 ----
> 3 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
> index 5b1f271c6034..ae2bb8970f63 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -50,6 +50,21 @@ static void acpiphp_sanitize_bus(struct pci_bus *bus);
> static void hotplug_event(u32 type, struct acpiphp_context *context);
> static void free_bridge(struct kref *kref);
>
> +static bool hotplug_is_native(struct pci_dev *bridge)
> +{
> + u32 slot_cap;
> +
> + pcie_capability_read_dword(bridge, PCI_EXP_SLTCAP, &slot_cap);
> +
> + if (slot_cap & PCI_EXP_SLTCAP_HPC && pciehp_is_native(bridge))
> + return true;
> +
> + if (shpchp_is_native(bridge))
> + return true;
> +
> + return false;
> +}
> +
> /**
> * acpiphp_init_context - Create hotplug context and grab a reference to it.
> * @adev: ACPI device object to create the context for.
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> index b78e0e417324..57bce9cc8a38 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -816,15 +816,10 @@ int pci_acpi_program_hp_params(struct pci_dev *dev)
> bool pciehp_is_native(struct pci_dev *bridge)
> {
> const struct pci_host_bridge *host;
> - u32 slot_cap;
>
> if (!IS_ENABLED(CONFIG_HOTPLUG_PCI_PCIE))
> return false;
>
> - pcie_capability_read_dword(bridge, PCI_EXP_SLTCAP, &slot_cap);
> - if (!(slot_cap & PCI_EXP_SLTCAP_HPC))
> - return false;
> -
> if (pcie_ports_native)
> return true;
>
> diff --git a/include/linux/pci_hotplug.h b/include/linux/pci_hotplug.h
> index ec77ccf1fc4d..02efeea62b25 100644
> --- a/include/linux/pci_hotplug.h
> +++ b/include/linux/pci_hotplug.h
> @@ -102,8 +102,4 @@ static inline bool pciehp_is_native(struct pci_dev *bridge) { return true; }
> static inline bool shpchp_is_native(struct pci_dev *bridge) { return true; }
> #endif
>
> -static inline bool hotplug_is_native(struct pci_dev *bridge)
> -{
> - return pciehp_is_native(bridge) || shpchp_is_native(bridge);
> -}
> #endif
> --
> 2.47.2
>
next prev parent reply other threads:[~2025-06-24 14:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-23 17:08 [PATCH] PCI/ACPI: Fix runtime PM ref imbalance on hot-plug capable ports Lukas Wunner
2025-06-23 17:15 ` Rafael J. Wysocki
2025-06-23 21:59 ` Mario Limonciello
2025-06-24 4:42 ` Mika Westerberg
2025-06-24 14:24 ` Bjorn Helgaas [this message]
2025-06-25 7:37 ` Lukas Wunner
2025-06-25 8:56 ` Rafael J. Wysocki
2025-06-25 19:32 ` Bjorn Helgaas
2025-06-26 5:20 ` Lukas Wunner
2025-06-26 5:30 ` Lukas Wunner
2025-06-26 9:47 ` Rafael J. Wysocki
2025-06-26 11:59 ` Ilpo Järvinen
2025-06-27 2:56 ` Bjorn Helgaas
2025-07-13 15:20 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250624142407.GA1473261@bhelgaas \
--to=helgaas@kernel.org \
--cc=bigon@bigon.be \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mario.limonciello@amd.com \
--cc=rafael@kernel.org \
--cc=westeri@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.