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

On Wed, 5 Nov 2008, Ingo Molnar 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.

OK, agree. We can have a debug patch that converts it back to normal
spinlocks that we can apply when we want to test it. But for release, we
just keep the raw_spin_locks.

-- Steve



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