Re: [PATCH 0/5] [GIP PULL] tracing/events/trace_stack: variousfixes

[Steven Rostedt]

On Mon, 8 Jun 2009, Peter Zijlstra wrote:

> On Mon, 2009-06-08 at 11:37 -0400, Steven Rostedt wrote:
> > [ Added Peter ]
> > 
> > On Sun, 7 Jun 2009, Ingo Molnar wrote:
> > > Testing tracer sched_switch: <6>Starting ring buffer hammer
> > > PASSED
> > > Testing tracer sysprof: PASSED
> > > Testing tracer function: PASSED
> > > Testing tracer irqsoff: 
> > > =============================================
> > > PASSED
> > > Testing tracer preemptoff: PASSED
> > > Testing tracer preemptirqsoff: [ INFO: possible recursive locking detected ]
> > > PASSED
> > > Testing tracer branch: 2.6.30-rc8-tip-01972-ge5b9078-dirty #5760
> > > ---------------------------------------------
> > > rb_consumer/431 is trying to acquire lock:
> > >  (&cpu_buffer->reader_lock){......}, at: [<c109eef7>] ring_buffer_reset_cpu+0x37/0x70
> > > 
> > > but task is already holding lock:
> > >  (&cpu_buffer->reader_lock){......}, at: [<c10a019e>] ring_buffer_consume+0x7e/0xc0
> > > 
> > > other info that might help us debug this:
> > > 1 lock held by rb_consumer/431:
> > >  #0:  (&cpu_buffer->reader_lock){......}, at: [<c10a019e>] ring_buffer_consume+0x7e/0xc0
> > 
> > Yes this definitely looks like ftrace is tracing the ring buffer benchmark 
> > test.
> > 
> > OK, how do I go about teaching lockdep that this reader lock is not the 
> > same reader lock as the one being taken?
> 
> Something like this will put each ring-buffer user in its own lock
> class.

Thanks a lot Peter. I'll see if I can get this to work and then push it 
off to Ingo to see if it fixes his lockdep bugs.

> 
> Patch utterly uncompiled and broken since hotplug would need some care
> (you could probably store the key pointer in the rb object and reuse it
> on hotplug).

I could also save the key in the ring buffer itself. Each of the per cpu 
reader locks will share the same key, and then when it is created by the 
hotplug, it will use the key of the ring buffer.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/