From: Nicolin Chen <nicolinc@nvidia.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: <bhelgaas@google.com>, <joerg.roedel@amd.com>,
<kevin.tian@intel.com>, <jgg@nvidia.com>,
<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<xueshuai@linux.alibaba.com>
Subject: Re: [PATCH rc] PCI: Fix nested pci_dev_reset_iommu_prepare/done()
Date: Wed, 18 Mar 2026 16:35:01 -0700 [thread overview]
Message-ID: <abs2pTxKL6pJzu7R@Asurada-Nvidia> (raw)
In-Reply-To: <20260318225705.GA479639@bhelgaas>
Hi Bjorn,
On Wed, Mar 18, 2026 at 05:57:05PM -0500, Bjorn Helgaas wrote:
> On Wed, Mar 18, 2026 at 03:00:28PM -0700, Nicolin Chen wrote:
> > Shuai found that cxl_reset_bus_function() calls pci_reset_bus_function()
> > internally while both are calling pci_dev_reset_iommu_prepare/done().
> >
> > This results in a nested pci_dev_reset_iommu_prepare/done() call:
> > cxl_reset_bus_function():
> > pci_dev_reset_iommu_prepare(); // outer
> > pci_reset_bus_function():
> > pci_dev_reset_iommu_prepare(); // inner (re-entry)
> > ...
> > pci_dev_reset_iommu_done(); // inner
> > pci_dev_reset_iommu_done(); // outer
> >
> > However, pci_dev_reset_iommu_prepare() doesn't allow a re-entry for now.
> >
> > Digging further, I found that most functions in pci_dev_specific_reset()
> > except reset_ivb_igd() are calling pcie_flr() that has nested those two
> > functions as well.
> >
> > Drop the outer callbacks in:
> > - cxl_reset_bus_function()
> > - pci_dev_specific_reset()
> >
> > Replace with adding the callbacks in:
> > + reset_ivb_igd()
>
> This needs to say clearly what the issue is. Deadlock? Crash?
> Corruption?
>
> I guess it's a deadlock when the second call to
> pci_dev_reset_iommu_prepare() acquires the group->mutex?
It will trigger a WARN_ON and fail the inner reset function:
/* Re-entry is not allowed */
if (WARN_ON(group->resetting_domain))
return -EBUSY;
> Since f5b16b802174 appeared in v7.0-rc1 (merged by Joerg), I guess
> this fix also needs to be in v7.0 -- please confirm.
Yes. I marked it "PATCH rc", hoping to cover that.
I'll send a v2 explicitly mentioning the WARN_ON and -EBUSY failure.
Nicolin
next prev parent reply other threads:[~2026-03-18 23:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 22:00 [PATCH rc] PCI: Fix nested pci_dev_reset_iommu_prepare/done() Nicolin Chen
2026-03-18 22:57 ` Bjorn Helgaas
2026-03-18 23:35 ` Nicolin Chen [this message]
2026-03-19 2:22 ` Tian, Kevin
2026-03-19 2:42 ` Nicolin Chen
2026-03-19 3:00 ` Tian, Kevin
2026-03-19 3:06 ` Nicolin Chen
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=abs2pTxKL6pJzu7R@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=jgg@nvidia.com \
--cc=joerg.roedel@amd.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=xueshuai@linux.alibaba.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.