From: Keith Busch <kbusch@kernel.org>
To: Keith Busch <kbusch@meta.com>
Cc: linux-pci@vger.kernel.org, bhelgaas@google.com, lukas@wunner.de,
mika.westerberg@linux.intel.com
Subject: Re: [PATCH RFC 0/8] pci: rescan/remove locking rework
Date: Wed, 7 Aug 2024 08:40:23 -0700 [thread overview]
Message-ID: <ZrOVZ04UzAOp5O-Z@kbusch-mbp> (raw)
In-Reply-To: <20240722151936.1452299-1-kbusch@meta.com>
On Mon, Jul 22, 2024 at 08:19:28AM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
>
> This patch set targets a subset of pci bus scanning and removals that
> were shown to be problematic with deep pci topologies that support
> native hotplug. I've tried to capture the common pci components, but
> there are definitely many subsystems accessing the topology in their own
> way, many of which I can't possibly test, and I have not tried to
> convert every user to this new locking scheme. However, if I did this
> correctly, they should be no worse off than today!
>
> The earlier patches are just cleanups and/or making it a little easier
> to change the locking schemes. The real stuff happens from patches 7 and
> 8.
>
> I've run this with lockdep enabled, tested concurrent hotplug events on
> various x86 platforms with layers of pci switches. That said, as
> mentioned earlier, there are many paths to here that I haven't been able
> to test, so the final patch might be considered experimental.
Any thoughts on this new scheme? I know I sent this during the merge
window, so maybe bad timing on my part. Changing the locks like this is
kind of scary too, so if that's the case, could we reconsider the
band-aid patch from before?
https://lore.kernel.org/linux-pci/20240612181625.3604512-2-kbusch@meta.com/
prev parent reply other threads:[~2024-08-07 15:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-22 15:19 [PATCH RFC 0/8] pci: rescan/remove locking rework Keith Busch
2024-07-22 15:19 ` [PATCH RFC 1/8] pci: make pci_stop_dev concurrent safe Keith Busch
2024-08-15 14:17 ` Jonathan Cameron
2024-08-20 15:02 ` Keith Busch
2024-08-21 11:01 ` Jonathan Cameron
2024-07-22 15:19 ` [PATCH RFC 2/8] pci: make pci_destroy_dev " Keith Busch
2024-08-15 14:18 ` Jonathan Cameron
2024-07-22 15:19 ` [PATCH RFC 3/8] pci: move the walk bus lock to where its needed Keith Busch
2024-08-15 14:20 ` Jonathan Cameron
2024-07-22 15:19 ` [PATCH RFC 4/8] pci: walk bus recursively Keith Busch
2024-08-15 14:33 ` Jonathan Cameron
2024-07-22 15:19 ` [PATCH RFC 5/8] pci: unexport pci_walk_bus_locked Keith Busch
2024-08-15 14:36 ` Jonathan Cameron
2024-07-22 15:19 ` [PATCH RFC 6/8] pci: add helpers for stop and remove bus Keith Busch
2024-08-15 14:49 ` Jonathan Cameron
2024-07-22 15:19 ` [PATCH RFC 7/8] pci: reference count subordinate Keith Busch
2024-08-15 15:10 ` Jonathan Cameron
2024-07-22 15:19 ` [PATCH RFC 8/8] pci: use finer grain locking for bus protection Keith Busch
2024-08-15 15:21 ` Jonathan Cameron
2024-08-15 17:05 ` Keith Busch
2024-08-07 15:40 ` 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=ZrOVZ04UzAOp5O-Z@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=bhelgaas@google.com \
--cc=kbusch@meta.com \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox