Messages in this thread | | | Subject | Re: [PATCH 1/7] lockdep: Print a nice description of an irq locking issue | From | Steven Rostedt <> | Date | Thu, 21 Apr 2011 07:40:29 -0400 |
| |
On Thu, 2011-04-21 at 15:02 +0800, Yong Zhang wrote: > On Thu, Apr 21, 2011 at 9:41 AM, Steven Rostedt <rostedt@goodmis.org> wrote: > > --- > > > > The above is the case when the unsafe lock is taken while holding > > a lock taken in irq context. But when a lock is taken that also > > grabs a unsafe lock, the call chain is shown: > > > > --- > > other info that might help us debug this: > > > > Chain exists of: > > &rq->lock --> lockA --> lockC > > > > Possible interrupt unsafe locking scenario: > > > > CPU0 CPU1 > > ---- ---- > > lock(lockC); > > local_irq_disable(); > > lock(&rq->lock); > > lock(lockA); > > <Interrupt> > > lock(&rq->lock); > > > > *** DEADLOCK *** > > Or we could show this: > Chain exists of: > &rq->lock --> lockA --> lockC > > Possible interrupt unsafe locking scenario: > > CPU0 CPU1 CPU2 > ---- ---- ---- > lock(lockC); > local_irq_disable(); > lock(&rq->lock); lock(lockA); > lock(lockA); lock(lockC); > <Interrupt> > lock(&rq->lock); > > *** DEADLOCK ***
We could but I prefer not to ;) We have some chains that are 8 locks deep. I really don't want to scatter that entirely across the screen. Hence my "Chain exists.." statement, following an example that any kernel developer can (with a little thinking) see is a possible deadlock.
In fact, this code doesn't even look at the full chain, it only examines 3 locks in the chain, and lets the developer figure out the rest. I could show the entire chain too.
Thanks,
-- Steve
| |