diff options
author | Alexey Kardashevskiy <aik@ozlabs.ru> | 2021-03-01 17:36:53 +1100 |
---|---|---|
committer | Michael Ellerman <mpe@ellerman.id.au> | 2021-04-23 01:38:04 +1000 |
commit | cc7130bf119add37f36238343a593b71ef6ecc1e (patch) | |
tree | 87079ec312685b7511dcc606b0ac196f0c203790 /drivers/usb/cdns3/cdns3-trace.h | |
parent | 4be518d838809e21354f32087aa9c26efc50b410 (diff) | |
download | linux-stable-cc7130bf119add37f36238343a593b71ef6ecc1e.tar.gz linux-stable-cc7130bf119add37f36238343a593b71ef6ecc1e.tar.bz2 linux-stable-cc7130bf119add37f36238343a593b71ef6ecc1e.zip |
powerpc/iommu: Annotate nested lock for lockdep
The IOMMU table is divided into pools for concurrent mappings and each
pool has a separate spinlock. When taking the ownership of an IOMMU group
to pass through a device to a VM, we lock these spinlocks which triggers
a false negative warning in lockdep (below).
This fixes it by annotating the large pool's spinlock as a nest lock
which makes lockdep not complaining when locking nested locks if
the nest lock is locked already.
===
WARNING: possible recursive locking detected
5.11.0-le_syzkaller_a+fstn1 #100 Not tainted
--------------------------------------------
qemu-system-ppc/4129 is trying to acquire lock:
c0000000119bddb0 (&(p->lock)/1){....}-{2:2}, at: iommu_take_ownership+0xac/0x1e0
but task is already holding lock:
c0000000119bdd30 (&(p->lock)/1){....}-{2:2}, at: iommu_take_ownership+0xac/0x1e0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(p->lock)/1);
lock(&(p->lock)/1);
===
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210301063653.51003-1-aik@ozlabs.ru
Diffstat (limited to 'drivers/usb/cdns3/cdns3-trace.h')
0 files changed, 0 insertions, 0 deletions