linux-kernel - Re: [PATCH 0/5] [GIP PULL] tracing/events/trace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0906081220040.9522@gandalf.stny.rr.com>
Date:	Mon, 8 Jun 2009 12:22:21 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 0/5] [GIP PULL] tracing/events/trace_stack: various
 fixes


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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/