All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: Farhan Ali <alifm@linux.ibm.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org, Riana Tauro <riana.tauro@intel.com>,
	Alex Williamson <alex@shazbot.org>
Subject: Re: [PATCH] PCI: Fix order of device disablement on reset
Date: Thu, 17 Sep 2026 08:04:27 -0600	[thread overview]
Message-ID: <aqvza2g_ptLvZjQL@kbusch-mbp> (raw)
In-Reply-To: <aqvfUldY5mGMMYrG@wunner.de>

On Thu, Sep 17, 2026 at 02:38:42PM +0200, Lukas Wunner wrote:
> On Tue, Sep 15, 2026 at 10:08:32AM -0700, Farhan Ali wrote:
> > 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:
> [...]
> > 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?
> 
> We only enabled error reporting by default starting with v6.0 in 2022,
> cf. commit f26e58bf6f54.
> 
> And the reset_subordinate sysfs attribute only exists since v6.13 in 2025,
> cf. commit 2fa046449a82.
> 
> So it's relatively new functionality which apparently wasn't exercised
> heavily so far.

Yeah, we've used it to reset multi-function devices, but a deeper
topology like you described does look problematic here. Your proposal
makes the save state symmetrical with the restore side, so looks correct
to me.

      reply	other threads:[~2026-09-17 14:04 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
2026-09-17 12:38   ` Lukas Wunner
2026-09-17 14:04     ` Keith Busch [this message]

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=aqvza2g_ptLvZjQL@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=alex@shazbot.org \
    --cc=alifm@linux.ibm.com \
    --cc=helgaas@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.