lkml.org 
[lkml]   [2008]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: bug: ftrace & lockdep badness

* Steven Rostedt <rostedt@goodmis.org> wrote:

>
> On Wed, 5 Nov 2008, Ingo Molnar wrote:
>
> >
> > * Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > > This is the type of problems we deal with when we have the tracer
> > > tracing lockdep code at the same time the lockdep code is checking
> > > the tracer.
> >
> > ok ... you are right, i guess we need to go back to raw locks after
> > all?
>
> I do like the fact that lockdep checks it too. But there's times
> that we can not do that.
>
> Perhaps we can do something in between.
>
> Make a rb_spin_lock macro inside ring_buffer.c that can be either a
> spin_lock or a raw_spin_lock. There are some tracers that must have
> this as a raw (function trace, irqsoff and preemptoff), but the rest
> should be fine. We can make it where the rb_spin_lock is a raw lock
> when any of those three tracers are configured, and make it into a
> normal lock when they are not.
>
> This way we can still test the integrity of the ring_buffer for
> other tracers. We just need to be careful when we are using function
> tracing or irqs/preempt off tracing. But we need to be careful with
> those anyway.

i'd rather we not complicate this anymore and just go for raw locks
unconditionally - or no raw locks unconditionally.

Ingo


\
 
 \ /
  Last update: 2008-11-05 18:11    [W:0.042 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site