[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHttsrZz866PnVX=GSxQOjqYL_E4HNjtrUfCcEFs7FMtxK8O0Q@mail.gmail.com>
Date: Wed, 10 Jul 2019 14:30:07 +0800
From: Yuyang Du <duyuyang@...il.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will.deacon@....com>,
Ingo Molnar <mingo@...nel.org>,
Bart Van Assche <bvanassche@....org>, ming.lei@...hat.com,
Frederic Weisbecker <frederic@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Waiman Long <longman@...hat.com>, paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH v3 30/30] locking/lockdep: Remove irq-safe to irq-unsafe
read check
Thanks for review.
On Wed, 10 Jul 2019 at 13:30, Boqun Feng <boqun.feng@...il.com> 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
Powered by blists - more mailing lists