On Tue, Nov 14, 2023 at 04:57:01PM +0100, Lukas Wunner wrote: > On Tue, Nov 14, 2023 at 02:04:34PM +0200, Andy Shevchenko wrote: > > On Tue, Nov 14, 2023 at 11:47:15AM +0100, Heiner Kallweit wrote: > > > On 14.11.2023 11:16, Wolfram Sang wrote: > > > > On Tue, Nov 14, 2023 at 06:54:29AM +0000, Shinichiro Kawasaki wrote: ... > > > > > The lockdep splat indicates possible deadlock between > > > > > pci_rescan_remove_lock and work_completion lock have deadlock > > > > > possibility. > > > > > In the call stack, I found that the workqueue thread for > > > > > i801_probe() calls p2sb_bar(), which locks pci_rescan_remove_lock. > > > > > > i801 just uses p2sb_bar(), I don't see any issue in i801. Root cause > > > seems to be in the PCI subsystem. Calling p2sb_bar() from a PCI driver > > > probe callback seems to be problematic, nevertheless it's a valid API > > > usage. > > > > So, currently I'm lack of (good) ideas and would like to hear other (more > > experienced) PCI developers on how is to address this... > > Can you add a p2sb_bar_locked() library call which is used by the > i801 probe path? > > Basically rename p2sb_bar() to __p2sb_bar() and add a third parameter > of type boolean which signifies whether it's invoked in locked context > or not, then call that from p2sb_bar() and p2sb_bar_locked() wrappers. It may work, I assume. Let me cook the patch. -- With Best Regards, Andy Shevchenko
