Created attachment 252371 [details] lockdep output Lockdep reports the following. Full lockdep output attached. This happens to be on a Google kernel but I think it's applicable to upstream as well. [ INFO: possible circular locking dependency detected ] 4.3.5-dbg-DEV #5 Tainted: G O ------------------------------------------------------- insmod/16742 is trying to acquire lock: (&p->pi_lock){-.-.-.}, at: [<ffffffffa1d155ac>] try_to_wake_up+0x3c/0x460 but task is already holding lock: (pci_cfg_wait.lock){......}, at: [<ffffffffa1d334c2>] __wake_up+0x32/0x70 which lock already depends on the new lock.
Created attachment 252391 [details] reproducer To reproduce this problem, build a kernel with CONFIG_PROVE_LOCKING=y, then untar this attachment and build the test module: $ cd kernel; make M=/path/to/mksplat/dir Boot the kernel, then: # perf stat -a -e uncore_imc_0/event=0x0/ -I 1000 # insmod ./mksplat.ko # sleeps for 10 seconds In another window, while mksplat is sleeping: # lspci -s 0000:00:00.0 -xxx # dmesg You may have to adjust the PCI device based on what's printed by mksplat. You should see the lspci wait for mksplat to finish sleeping, and lockdep should give a complaint about the circular locking. This is adapted slightly from what I used internally, so I *think* this should reproduce the problem but can't vouch for it 100%.
This should be fixed by cdcb33f98244 ("PCI: Avoid possible deadlock on pci_lock and p->pi_lock"), which appeared in v4.11-rc1. http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?id=cdcb33f98244