[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1261410984.25193.8.camel@gandalf.stny.rr.com>
Date: Mon, 21 Dec 2009 10:56:24 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Li Zefan <lizf@...fujitsu.com>, Ingo Molnar <mingo@...e.hu>,
Frederic Weisbecker <fweisbec@...il.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tracing: Fix lockdep warning in global_clock()
On Mon, 2009-12-21 at 15:40 +0100, Peter Zijlstra wrote:
> On Mon, 2009-12-21 at 15:36 +0800, Li Zefan wrote:
>
> > +++ b/kernel/sched_clock.c
> > @@ -250,9 +250,9 @@ unsigned long long cpu_clock(int cpu)
> > unsigned long long clock;
> > unsigned long flags;
> >
> > - raw_local_irq_save(flags);
> > + local_irq_save(flags);
> > clock = sched_clock_cpu(cpu);
> > - raw_local_irq_restore(flags);
> > + local_irq_restore(flags);
> >
> > return clock;
> > }
> > ===============================================
> >
> > I guess it's still true that lower level functions can take locks?
>
> No, I removed the locks from cpu_clock a while back.
>
The problem isn't with locks, it's with disabling interrupts. Lockdep
keeps track of every time interrupts are disabled. If something disables
interrupts with raw_* but then calls something that disables interrupts
the normal way, lockdep will detect that interrupts are being disabled
but they already are disabled. The internal irq disabled variable in
lockdep wont match reality, and this will blow up (well, disable
lockdep).
So if cpu_clock disables interrupts with local_irq_* then so must
trace_clock_global.
-- 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/
Powered by blists - more mailing lists