From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH 2/2] tracing/events/lockdep: move tracepoints within recursive protection
Date: Fri, 17 Apr 2009 09:40:49 +0200 [thread overview]
Message-ID: <1239954049.23397.4156.camel@laptop> (raw)
In-Reply-To: <alpine.DEB.2.00.0904162319010.20429@gandalf.stny.rr.com>
On Thu, 2009-04-16 at 23:24 -0400, Steven Rostedt wrote:
> > Either there's a bug in the vbin_printf, or we have some crazy lock->name?
> >
> > TRACE_FORMAT(lock_acquire,
> > TP_PROTO(struct lockdep_map *lock, unsigned int subclass,
> > int trylock, int read, int check,
> > struct lockdep_map *next_lock, unsigned long ip),
> > TP_ARGS(lock, subclass, trylock, read, check, next_lock, ip),
> > TP_FMT("%s%s%s", trylock ? "try " : "",
> > read ? "read " : "", lock->name)
> > );
> >
> > I'll continue to look into this, and perhaps reboot and see what other
> > nasties I hit.
>
> OK, I think I figured this bug out. This is a lockdep issue with respect
> to tracepoints.
>
> The trace points in lockdep are called all the time. Outside the lockdep
> logic. But if lockdep were to trigger an error / warning (which this run
> did) we might be in trouble. For new locks, like the dentry->d_lock, that
> are created, they will not get a name:
>
> void lockdep_init_map(struct lockdep_map *lock, const char *name,
> struct lock_class_key *key, int subclass)
> {
> if (unlikely(!debug_locks))
> return;
>
> When a problem is found by lockdep, debug_locks becomes false. Thus we
> stop allocating names for locks. This dentry->d_lock I had, now has no
> name. Worse yet, I have CONFIG_DEBUG_VM set, that scrambles non
> initialized memory. Thus, when the trace point was hit, it had junk for
> the lock->name, and the machine crashed.
Ah, nice catch. I think we should put at least the name in regardless.
Something like the below ought to do I guess:
---
Subject: lockdep: more robust lockdep_map init sequence
Ensure we at least initialize the trivial entries of the depmap so that
they can be relied upon, even when lockdep itself decided to pack up and
go home.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/lockdep.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index c4582a6..4516e5b 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -2490,13 +2490,20 @@ static int mark_lock(struct task_struct *curr, struct held_lock *this,
void lockdep_init_map(struct lockdep_map *lock, const char *name,
struct lock_class_key *key, int subclass)
{
- if (unlikely(!debug_locks))
+ lock->class_cache = NULL;
+#ifdef CONFIG_LOCK_STAT
+ lock->cpu = raw_smp_processor_id();
+#endif
+
+ if (DEBUG_LOCKS_WARN_ON(!name)) {
+ lock->name = "NULL";
return;
+ }
+
+ lock->name = name;
if (DEBUG_LOCKS_WARN_ON(!key))
return;
- if (DEBUG_LOCKS_WARN_ON(!name))
- return;
/*
* Sanity check, the lock-class key must be persistent:
*/
@@ -2505,12 +2512,11 @@ void lockdep_init_map(struct lockdep_map *lock, const char *name,
DEBUG_LOCKS_WARN_ON(1);
return;
}
- lock->name = name;
lock->key = key;
- lock->class_cache = NULL;
-#ifdef CONFIG_LOCK_STAT
- lock->cpu = raw_smp_processor_id();
-#endif
+
+ if (unlikely(!debug_locks))
+ return;
+
if (subclass)
register_lock_class(lock, subclass, 1);
}
next prev parent reply other threads:[~2009-04-17 7:41 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-16 16:15 [PATCH 0/2] [GIT PULL] updates for event tester and lockdep tracer Steven Rostedt
2009-04-16 16:15 ` [PATCH 1/2] tracing/events: perform function tracing in event selftests Steven Rostedt
2009-04-17 16:10 ` [tip:tracing/core] " tip-bot for Steven Rostedt
2009-04-16 16:15 ` [PATCH 2/2] tracing/events/lockdep: move tracepoints within recursive protection Steven Rostedt
2009-04-16 16:47 ` Peter Zijlstra
2009-04-16 17:03 ` Steven Rostedt
2009-04-16 17:20 ` Peter Zijlstra
2009-04-16 17:38 ` Steven Rostedt
2009-04-16 17:49 ` Peter Zijlstra
2009-04-16 17:58 ` Steven Rostedt
2009-04-16 18:06 ` Peter Zijlstra
2009-04-16 18:12 ` Steven Rostedt
2009-04-16 18:29 ` Mathieu Desnoyers
2009-04-16 18:22 ` Mathieu Desnoyers
2009-04-16 17:45 ` Steven Rostedt
2009-04-16 17:53 ` Peter Zijlstra
2009-04-17 3:03 ` Steven Rostedt
2009-04-17 3:24 ` Steven Rostedt
2009-04-17 7:40 ` Peter Zijlstra [this message]
2009-04-17 16:03 ` [tip:core/urgent] lockdep: more robust lockdep_map init sequence tip-bot for Peter Zijlstra
2009-04-17 4:16 ` [PATCH 2/2] tracing/events/lockdep: move tracepoints within recursive protection Steven Rostedt
2009-04-17 4:36 ` Steven Rostedt
2009-04-17 4:52 ` Mathieu Desnoyers
2009-04-17 11:09 ` Steven Rostedt
2009-04-17 22:19 ` [PATCH] x86 entry_64.S lockdep fix Mathieu Desnoyers
2009-04-18 13:54 ` Steven Rostedt
2009-04-19 4:11 ` Mathieu Desnoyers
2009-04-19 9:10 ` Ingo Molnar
2009-04-17 7:44 ` [PATCH 2/2] tracing/events/lockdep: move tracepoints within recursive protection Peter Zijlstra
2009-04-16 16:40 ` [PATCH 0/2] [GIT PULL] updates for event tester and lockdep tracer Ingo Molnar
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=1239954049.23397.4156.camel@laptop \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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