summaryrefslogtreecommitdiffstats
path: root/drivers/usb/cdns3/cdns3-trace.h
diff options
context:
space:
mode:
authorAlexey Kardashevskiy <aik@ozlabs.ru>2021-03-01 17:36:53 +1100
committerMichael Ellerman <mpe@ellerman.id.au>2021-04-23 01:38:04 +1000
commitcc7130bf119add37f36238343a593b71ef6ecc1e (patch)
tree87079ec312685b7511dcc606b0ac196f0c203790 /drivers/usb/cdns3/cdns3-trace.h
parent4be518d838809e21354f32087aa9c26efc50b410 (diff)
downloadlinux-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