Thanks for review. On Wed, 10 Jul 2019 at 13:30, Boqun Feng <[email protected]> wrote: > > On Fri, Jun 28, 2019 at 05:15:28PM +0800, Yuyang Du wrote: > > We have a lockdep warning: > > > > ======================================================== > > WARNING: possible irq lock inversion dependency detected > > 5.1.0-rc7+ #141 Not tainted > > -------------------------------------------------------- > > kworker/8:2/328 just changed the state of lock: > > 0000000007f1a95b (&(&host->lock)->rlock){-...}, at: > > ata_bmdma_interrupt+0x27/0x1c0 [libata] > > but this lock took another, HARDIRQ-READ-unsafe lock in the past: > > (&trig->leddev_list_lock){.+.?} > > > > and interrupts could create inverse lock ordering between them. > > > > other info that might help us debug this: > > Possible interrupt unsafe locking scenario: > > > > CPU0 CPU1 > > ---- ---- > > lock(&trig->leddev_list_lock); > > local_irq_disable(); > > lock(&(&host->lock)->rlock); > > lock(&trig->leddev_list_lock); > > <Interrupt> > > lock(&(&host->lock)->rlock); > > > > *** DEADLOCK *** > > > > This splat is a false positive, which is enabled by the addition of > > If so, I think the better way is to reorder this patch before recursive > read lock suppport, for better bisect-ability.
Good suggestion. Thanks, Yuyang
