From: Steven Rostedt <rostedt@goodmis.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>, Ingo Molnar <mingo@elte.hu>,
Frederic Weisbecker <fweisbec@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] tracing: Fix lockdep warning in global_clock()
Date: Mon, 21 Dec 2009 10:56:24 -0500 [thread overview]
Message-ID: <1261410984.25193.8.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <1261406427.4314.155.camel@laptop>
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
next prev parent reply other threads:[~2009-12-21 15:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-21 6:27 Li Zefan
2009-12-21 6:43 ` Ingo Molnar
2009-12-21 7:36 ` Li Zefan
2009-12-21 14:40 ` Peter Zijlstra
2009-12-21 15:56 ` Steven Rostedt [this message]
2009-12-22 5:17 ` Li Zefan
2009-12-22 6:16 ` Yong Zhang
2009-12-22 8:23 ` Peter Zijlstra
2009-12-23 0:59 ` Li Zefan
2009-12-21 15:49 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1261410984.25193.8.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®