Hello Denis,
On 3/22/24 12:03, Denis Nikitin wrote:
Hello CoreSight friends,
There is a bug recently reported on ChromeOS (with the linux kernel 6.6), https://issuetracker.google.com/329285580. Lockdep detected a deadlock in TMC ETR in a debug kernel build.
[12453.456471] WARNING: possible circular locking dependency detected [12453.456518] 6.6.21-lockdep-01250-gbecf1787b73c #1 Not tainted [12453.456575] ------------------------------------------------------ [12453.456618] perf/12414 is trying to acquire lock: [12453.456671] ffffffc084bc0990 (&dma_entry_hash[i].lock){-.-.}-{2:2}, at: check_sync+0x84/0x11a0 [12453.456896] but task is already holding lock: [12453.456938] ffffff80cdb940f8 (&drvdata->spinlock){....}-{2:2}, at: tmc_update_etr_buffer+0xbc/0x898 [coresight_tmc] [12453.457332] which lock already depends on the new lock.
Could you please take a look?
Looking at the call chain for TMC ETR devices which might interact with DMA buffer operations.
etm_pmu->stop() etm_event_stop() sink_ops(sink)->update_buffer() tmc_update_etr_buffer() spin_lock_irqsave(&drvdata->spinlock, ...) tmc_sync_etr_buf(drvdata) spin_unlock_irqrestore(&drvdata->spinlock, ...)
tmc_sync_etr_buf() etr_buf->ops->sync(etr_buf, rrp, rwp) tmc_etr_sync_sg_buf() tmc_sg_table_sync_data_range() dma_sync_single_for_cpu(... DMA_TO_DEVICE) debug_dma_sync_single_for_cpu() check_sync() check_sync() get_hash_bucket() spin_lock_irqsave(&dma_entry_hash[idx].lock, ...) ----- printks() ---- put_hash_bucket() spin_unlock_irqrestore(&bucket->lock, ...)
Could it be that these printks() might be the root cause of the lockdep splats ? Should not printk() be avoided while locks are being held ? Similar problem might happen also via check_unmap() as being reported. Although I am also wondering if there is any real cyclic lock dependency here but without these DMA printks() in scenario ?
- Anshuman