Messages in this thread | | | Subject | Re: [RFC][PATCH] lockdep: Print a nice description of an irq locking issue | From | Steven Rostedt <> | Date | Tue, 29 Mar 2011 13:20:14 -0400 |
| |
On Tue, 2011-03-29 at 13:14 -0400, Steven Rostedt wrote: > > --- > 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 *** >
Note, the above output is real. To produce this output, I wrote a module that created a "lockA", "lockB" and "lockC" and had the following:
spin_lock_irq(&lockA); spin_lock(&lockB); spin_unlock(&lockB); spin_unlock_irq(&lockA);
spin_lock_irq(&lockB); spin_lock(&lockC); spin_unlock(&lockC); spin_unlock_irq(&lockB);
spin_lock(&lockC); spin_unlock(&lockC); ret = register_trace_sched_switch(probe_switch, NULL);
static void probe_switch(void *ignore, struct task_struct *p, struct task_struct *n) { unsigned long flags;
spin_lock_irqsave(&lockA, flags); spin_unlock_irqrestore(&lockA, flags); }
probe_switch is called via the trace_sched_switch() trace point that is called with the rq lock held, producing the call chain that will trigger lockdep to produce a dump.
-- Steve
| |