Message ID | 20210301063653.51003-1-aik@ozlabs.ru |
---|---|
State | New |
Headers | show |
Series | [kernel,v2] powerpc/iommu: Annotate nested lock for lockdep | expand |
On Mon, 1 Mar 2021 17:36:53 +1100, Alexey Kardashevskiy wrote: > 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. > > [...] Applied to powerpc/next. [1/1] powerpc/iommu: Annotate nested lock for lockdep https://git.kernel.org/powerpc/c/cc7130bf119add37f36238343a593b71ef6ecc1e cheers
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c index c1a5c366a664..d0df3e5ff5e0 100644 --- a/arch/powerpc/kernel/iommu.c +++ b/arch/powerpc/kernel/iommu.c @@ -1089,7 +1089,7 @@ int iommu_take_ownership(struct iommu_table *tbl) spin_lock_irqsave(&tbl->large_pool.lock, flags); for (i = 0; i < tbl->nr_pools; i++) - spin_lock(&tbl->pools[i].lock); + spin_lock_nest_lock(&tbl->pools[i].lock, &tbl->large_pool.lock); iommu_table_release_pages(tbl); @@ -1117,7 +1117,7 @@ void iommu_release_ownership(struct iommu_table *tbl) spin_lock_irqsave(&tbl->large_pool.lock, flags); for (i = 0; i < tbl->nr_pools; i++) - spin_lock(&tbl->pools[i].lock); + spin_lock_nest_lock(&tbl->pools[i].lock, &tbl->large_pool.lock); memset(tbl->it_map, 0, sz);
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> --- Changes: v2: * fixed iommu_release_ownership() as well --- arch/powerpc/kernel/iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)