From: Lukas Wunner <lukas@wunner.de>
To: Keith Busch <kbusch@meta.com>
Cc: linux-pci@vger.kernel.org, bhelgaas@google.com,
Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv2 1/2] PCI: pciehp: fix concurrent sub-tree removal deadlock
Date: Mon, 11 Nov 2024 09:00:18 +0100 [thread overview]
Message-ID: <ZzG5koPOn16KQ8uM@wunner.de> (raw)
In-Reply-To: <ZzG0W7LGrggNa6Qi@wunner.de>
On Mon, Nov 11, 2024 at 08:38:03AM +0100, Lukas Wunner wrote:
> Thinking about this some more:
>
> The problem is pci_lock_rescan_remove() is a single global lock.
>
> What if we introduce a lock at each bridge or for each pci_bus.
> Before a portion of the hierarchy is removed, all locks in that
> sub-hierarchy are acquired bottom-up.
>
> I think that should avoid the deadlock. Thoughts?
I note that you attempted something similar back in July:
https://lore.kernel.org/all/20240722151936.1452299-9-kbusch@meta.com/
However I'd suggest to solve this differently:
Keep the pci_lock_rescan_remove() everywhere, don't add pci_lock_bus()
adjacent to it.
Instead, amend pci_lock_rescan_remove() to walk the sub-hierarchy
bottom-up and acquire all the bus locks. Obviously you'll have to amend
pci_lock_rescan_remove() to accept a pci_dev which is the bridge atop
the sub-hierarchy. (Or alternatively, the top-most pci_bus in the
sub-hierarchy.)
Thanks,
Lukas
next prev parent reply other threads:[~2024-11-11 8:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 18:16 [PATCHv2 0/2] pcie hotplug and error fixes Keith Busch
2024-06-12 18:16 ` [PATCHv2 1/2] PCI: pciehp: fix concurrent sub-tree removal deadlock Keith Busch
2024-06-27 7:47 ` Lukas Wunner
2024-06-27 14:55 ` Keith Busch
2024-11-11 7:38 ` Lukas Wunner
2024-11-11 8:00 ` Lukas Wunner [this message]
2024-11-11 17:59 ` Keith Busch
2024-06-12 18:16 ` [PATCHv2 2/2] PCI: err: ensure stable topology during handling Keith Busch
2024-06-15 14:09 ` Lukas Wunner
2024-06-17 17: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=ZzG5koPOn16KQ8uM@wunner.de \
--to=lukas@wunner.de \
--cc=bhelgaas@google.com \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--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.