From: sashiko-bot@kernel.org
To: "Kuppuswamy Sathyanarayanan"
<sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v15 4/4] PCI: Centralize pci_aer_available() checking
Date: Sat, 03 Oct 2026 01:33:59 +0000 [thread overview]
Message-ID: <20261003013359.A38F61F00898@smtp.kernel.org> (raw)
In-Reply-To: <20261002211828.1293177-5-sathyanarayanan.kuppuswamy@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] pcie: stale host->native_aer enables AER after MSI is disabled
--
commit 905020873a7ae5dea6e2ab6198bde259d6bd9411
Author: Bjorn Helgaas <bhelgaas@google.com>
PCI: Centralize pci_aer_available() checking
This commit centralizes the pci_aer_available() check by evaluating it once
during host bridge initialization and storing the result in host->native_aer.
This aims to simplify callers by having them only check host->native_aer.
> diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
> index 32fc623dd4108..9f8c6dd434c55 100644
> --- a/drivers/pci/pcie/portdrv.c
> +++ b/drivers/pci/pcie/portdrv.c
> @@ -239,8 +239,7 @@ static int get_port_device_capability(struct pci_dev *dev)
> #ifdef CONFIG_PCIEAER
> if ((pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT ||
> pci_pcie_type(dev) == PCI_EXP_TYPE_RC_EC) &&
> - dev->aer_cap && pci_aer_available() &&
> - host->native_aer)
> + dev->aer_cap && host->native_aer)
[Severity: Medium]
Could this regression of removing the dynamic pci_aer_available() check
here lead to AER being erroneously enabled if MSI is disabled later during
enumeration?
Since pci_aer_available() requires MSI to be enabled, this code used to
prevent AER from starting if MSI was turned off dynamically. By relying
only on the statically cached host->native_aer, we might bypass that
requirement.
> services |= PCIE_PORT_SERVICE_AER;
> #endif
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 1e487a213eb0f..e1ca8096bcd58 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -670,7 +670,7 @@ static void pci_init_host_bridge(struct pci_host_bridge *bridge)
[ ... ]
> - bridge->native_aer = port_services;
> + bridge->native_aer = pci_aer_available();
[Severity: Medium]
Does this regression cache a stale value for pci_aer_available() if a
hardware quirk disables MSI after the host bridge is initialized?
For example, during device enumeration, quirk_disable_all_msi() might
be called for a specific device, disabling MSI globally:
drivers/pci/quirks.c:quirk_disable_all_msi() {
...
pci_no_msi();
...
}
If this happens after pci_init_host_bridge() has already run,
bridge->native_aer will remain true even though pci_aer_available() would
now return false.
The AER device could then bind to the already-registered driver and
erroneously enable AER without MSI support, potentially causing interrupt
storms or unhandled errors.
> bridge->native_pcie_hotplug = port_services;
> bridge->native_shpc_hotplug = 1;
> bridge->native_pme = port_services;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261002211828.1293177-1-sathyanarayanan.kuppuswamy@linux.intel.com?part=4
next prev parent reply other threads:[~2026-10-03 1:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 21:18 [PATCH v15 0/4] Simplify PCIe native ownership Kuppuswamy Sathyanarayanan
2026-10-02 21:18 ` [PATCH v15 1/4] PCI: Assume control of portdrv-related features only when portdrv enabled Kuppuswamy Sathyanarayanan
2026-10-03 1:33 ` sashiko-bot
2026-10-02 21:18 ` [PATCH v15 2/4] PCI/ACPI: Tidy _OSC control bit checking Kuppuswamy Sathyanarayanan
2026-10-03 1:33 ` sashiko-bot
2026-10-02 21:18 ` [PATCH v15 3/4] PCI/ACPI: Centralize pcie_ports_native checking Kuppuswamy Sathyanarayanan
2026-10-03 1:33 ` sashiko-bot
2026-10-02 21:18 ` [PATCH v15 4/4] PCI: Centralize pci_aer_available() checking Kuppuswamy Sathyanarayanan
2026-10-03 1:33 ` sashiko-bot [this message]
2026-10-05 18:04 ` Kuppuswamy Sathyanarayanan
2026-10-05 22:40 ` Bjorn Helgaas
2026-10-06 17:51 ` [PATCH v15 0/4] Simplify PCIe native ownership Bjorn Helgaas
2026-10-06 18:38 ` Kuppuswamy Sathyanarayanan
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=20261003013359.A38F61F00898@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
/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.