From: Leon Romanovsky <leon@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Kalle Valo <kvalo@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
bhelgaas@google.com, Imre Deak <imre.deak@intel.com>,
Jani Saarinen <jani.saarinen@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
linux-pci@vger.kernel.org, linux-cxl@vger.kernel.org
Subject: Re: [PATCH v2 1/3] PCI: Revert the cfg_access_lock lockdep mechanism
Date: Thu, 6 Jun 2024 13:04:18 +0300 [thread overview]
Message-ID: <20240606100418.GD13732@unreal> (raw)
In-Reply-To: <20240604171121.GA730808@bhelgaas>
On Tue, Jun 04, 2024 at 12:11:21PM -0500, Bjorn Helgaas wrote:
> On Tue, Jun 04, 2024 at 11:03:54AM +0300, Kalle Valo wrote:
> > Dan Williams <dan.j.williams@intel.com> writes:
> >
> > > While the experiment did reveal that there are additional places that
> > > are missing the lock during secondary bus reset, one of the places that
> > > needs to take cfg_access_lock (pci_bus_lock()) is not prepared for
> > > lockdep annotation.
> > >
> > > Specifically, pci_bus_lock() takes pci_dev_lock() recursively and is
> > > currently dependent on the fact that the device_lock() is marked
> > > lockdep_set_novalidate_class(&dev->mutex). Otherwise, without that
> > > annotation, pci_bus_lock() would need to use something like a new
> > > pci_dev_lock_nested() helper, a scheme to track a PCI device's depth in
> > > the topology, and a hope that the depth of a PCI tree never exceeds the
> > > max value for a lockdep subclass.
> > >
> > > The alternative to ripping out the lockdep coverage would be to deploy a
> > > dynamic lock key for every PCI device. Unfortunately, there is evidence
> > > that increasing the number of keys that lockdep needs to track to be
> > > per-PCI-device is prohibitively expensive for something like the
> > > cfg_access_lock.
> > >
> > > The main motivation for adding the annotation in the first place was to
> > > catch unlocked secondary bus resets, not necessarily catch lock ordering
> > > problems between cfg_access_lock and other locks. Solve that narrower
> > > problem with follow-on patches, and just due to targeted revert for now.
> > >
> > > Fixes: 7e89efc6e9e4 ("PCI: Lock upstream bridge for pci_reset_function()")
> > > Reported-by: Imre Deak <imre.deak@intel.com>
> > > Closes: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_134186v1/shard-dg2-1/igt@device_reset@unbind-reset-rebind.html
> > > Cc: Jani Saarinen <jani.saarinen@intel.com>
> > > Cc: Dave Jiang <dave.jiang@intel.com>
> > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> >
> > In our ath11k test box commit 7e89efc6e9e4 was causing random kernel
> > crashes. I tested patches 1-3 and did not see anymore crashes so:
> >
> > Tested-by: Kalle Valo <kvalo@kernel.org>
>
> Added to commit logs, thank you!
>
Thanks,
Tested-by: Leon Romanovsky <leonro@nvidia.com>
next prev parent reply other threads:[~2024-06-06 10:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 1:04 [PATCH v2 0/3] PCI: Revert / replace the cfg_access_lock lockdep mechanism Dan Williams
2024-05-31 1:04 ` [PATCH v2 1/3] PCI: Revert " Dan Williams
2024-05-31 18:05 ` Dave Jiang
2024-06-04 8:03 ` Kalle Valo
2024-06-04 17:11 ` Bjorn Helgaas
2024-06-06 10:04 ` Leon Romanovsky [this message]
2024-05-31 1:04 ` [PATCH v2 2/3] PCI: Warn on missing cfg_access_lock during secondary bus reset Dan Williams
2024-05-31 18:06 ` Dave Jiang
2024-05-31 1:04 ` [PATCH v2 3/3] PCI: Add missing bridge lock to pci_bus_lock() Dan Williams
2024-05-31 18:07 ` Dave Jiang
2024-06-28 19:25 ` Keith Busch
2024-05-31 21:31 ` [PATCH v2 0/3] PCI: Revert / replace the cfg_access_lock lockdep mechanism Bjorn Helgaas
2024-06-03 19:49 ` Hans de Goede
2024-06-03 20:37 ` Bjorn Helgaas
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=20240606100418.GD13732@unreal \
--to=leon@kernel.org \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=helgaas@kernel.org \
--cc=imre.deak@intel.com \
--cc=jani.saarinen@intel.com \
--cc=kvalo@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.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.