On Tue, Nov 14, 2023 at 06:11:40PM +0200, Andy Shevchenko wrote: > 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. Hmm... But this will open a window when probing phase happens, e.g. during boot time, no? If somebody somehow calls for full rescan, we may end up in the situation when P2SB is gone before accessing it in p2sb_bar(). Now I'm wondering why simple pci_dev_get() can't be sufficient in the p2sb_bar(). -- With Best Regards, Andy Shevchenko
