[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190923082832.GD2773@lahna.fi.intel.com>
Date: Mon, 23 Sep 2019 11:28:32 +0300
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Lukas Wunner <lukas@...ner.de>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Keith Busch <keith.busch@...el.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Frederick Lawler <fred@...dlawl.com>,
"Gustavo A . R . Silva" <gustavo@...eddedor.com>,
Sinan Kaya <okaya@...nel.org>,
Kai-Heng Feng <kai.heng.feng@...onical.com>,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] PCI: pciehp: Prevent deadlock on disconnect
On Mon, Sep 23, 2019 at 11:12:42AM +0300, Mika Westerberg wrote:
> Regarding suggestion of unbinding PCI drivers without
> pci_lock_rescan_remove() hold, I haven't looked it too closely but I
> think we need to take that lock anyway because when we are unbinding a
> hotplug driver it is supposed to remove the hierarchy below touching the
> shared structures, possibly concurrently. Unfortunately there is no
> documentation what data pci_lock_rescan_remove() actually protects so
> first one needs to understand that. I think one way to clean up this is
> to use finer grained locking (with documented lock ordering) for PCI bus
> structures that can be accessed simultaneusly by different threads. But
> that is not a simple task.
Now that I looked more closely, I realized it actually is not supposed
to remove the hierarchy below so indeed it might be possible to do that
without taking pci_lock_rescan_remove().
Powered by blists - more mailing lists