From: Farhan Ali <alifm@linux.ibm.com>
To: Lukas Wunner <lukas@wunner.de>, Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, Riana Tauro <riana.tauro@intel.com>,
Alex Williamson <alex@shazbot.org>,
Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH] PCI: Fix order of device disablement on reset
Date: Tue, 15 Sep 2026 10:08:32 -0700 [thread overview]
Message-ID: <6a45ad46-efa6-47fd-9408-302ea8bb66e2@linux.ibm.com> (raw)
In-Reply-To: <4c908eaab127d82ecfdc1e9948964b2e641d41d8.1789478646.git.lukas@wunner.de>
Hi Lukas,
On 9/15/2026 6:35 AM, Lukas Wunner wrote:
> Riana reports an AER splat when issuing a Secondary Bus Reset through the
> "reset_subordinate" sysfs attribute:
>
> AER: Multiple Uncorrectable (Non-Fatal) error message received from 0000:01:00.0
> PCIe Bus Error: severity=Uncorrectable (Non-Fatal), type=Transaction Layer, (Requester ID)
> device [8086:e2ff] error status/mask=00100000/00400000
> [20] UnsupReq (First)
> AER: TLP Header: 0x40000001 0x0000000f 0x81190008 0x00000000
>
> The Secondary Bus Reset is issued at the Root Port. Underneath is a
> Switch with two Endpoints. Riana has identified an ordering issue in
> pci_bus_save_and_disable_locked() as root cause of the AER splat:
> The function calls pci_dev_save_and_disable() for the Switch Upstream Port
> first, then recurses down to its subordinate devices.
>
> pci_dev_save_and_disable() quiesces a device by clearing its Command
> register (in accordance with PCIe r7.0 sec 6.6.2, "Implementation Note:
> Avoiding data corruption from stale completions").
>
> On devices with a Type 1 Configuration Space Header (such as the Switch
> Upstream Port), clearing the Command register causes MMIO accesses to
> subordinate devices to be handled as Unsupported Requests, as seen in
> the AER splat above (PCIe r7.0 sec 7.5.1.1.3 bit 1).
>
> The drivers of subordinate devices are only informed afterwards of the
> impending reset via their ->reset_prepare() callback. They get no chance
> to stop access to MMIO space before the Switch Upstream Port disables
> access.
>
> Reorder pci_bus_save_and_disable_locked() to recurse first and only then
> disable the Switch Upstream Port. This mirrors the order in
> pci_slot_restore_locked() and avoids the AER splat.
>
> Do the same in pci_slot_save_and_disable_locked() for consistency.
>
> Fixes: 090a3c5322e9 ("PCI: Add pci_reset_slot() and pci_reset_bus()")
> Reported-by: Riana Tauro <riana.tauro@intel.com> # off-list
> Tested-by: Riana Tauro <riana.tauro@intel.com>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: stable@vger.kernel.org # v3.12+
> ---
> drivers/pci/pci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6..ce9f74d 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5508,9 +5508,9 @@ static void pci_bus_save_and_disable_locked(struct pci_bus *bus)
> struct pci_dev *dev;
>
> list_for_each_entry(dev, &bus->devices, bus_list) {
> - pci_dev_save_and_disable(dev);
> if (dev->subordinate)
> pci_bus_save_and_disable_locked(dev->subordinate);
> + pci_dev_save_and_disable(dev);
> }
> }
>
Since we are changing the order, maybe we should update comment for the
functions to reflect that. The change does make sense to me, but I am
curious why we didn't see this before?
Thanks
Farhan
> @@ -5543,9 +5543,9 @@ static void pci_slot_save_and_disable_locked(struct pci_slot *slot)
> list_for_each_entry(dev, &slot->bus->devices, bus_list) {
> if (!dev->slot || dev->slot != slot)
> continue;
> - pci_dev_save_and_disable(dev);
> if (dev->subordinate)
> pci_bus_save_and_disable_locked(dev->subordinate);
> + pci_dev_save_and_disable(dev);
> }
> }
>
next prev parent reply other threads:[~2026-09-15 17:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 13:35 [PATCH] PCI: Fix order of device disablement on reset Lukas Wunner
2026-09-15 13:51 ` sashiko-bot
2026-09-15 17:08 ` Farhan Ali [this message]
2026-09-17 12:38 ` Lukas Wunner
2026-09-17 14:04 ` Keith Busch
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=6a45ad46-efa6-47fd-9408-302ea8bb66e2@linux.ibm.com \
--to=alifm@linux.ibm.com \
--cc=alex@shazbot.org \
--cc=helgaas@kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=riana.tauro@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.