Bug 192901
| Summary: | Deadlock with pci_lock and p->pi_lock | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Bjorn Helgaas (bjorn) |
| Component: | PCI | Assignee: | drivers_pci (drivers_pci) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | v4.3.5 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
lockdep output
reproducer |
||
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
|
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.