public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Peter Zijlstra <peterz@infradead.org>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@redhat.com,
	a.p.zijlstra@chello.nl, peterz@infradead.org, fweisbec@gmail.com,
	rostedt@goodmis.org, akpm@linux-foundation.org,
	tglx@linutronix.de, mingo@elte.hu
Subject: [tip:core/urgent] lockdep: more robust lockdep_map init sequence
Date: Fri, 17 Apr 2009 16:03:33 GMT	[thread overview]
Message-ID: <tip-c8a250058656495be02c00de61e26b017c86ef00@git.kernel.org> (raw)
In-Reply-To: <1239954049.23397.4156.camel@laptop>

Commit-ID:  c8a250058656495be02c00de61e26b017c86ef00
Gitweb:     http://git.kernel.org/tip/c8a250058656495be02c00de61e26b017c86ef00
Author:     Peter Zijlstra <peterz@infradead.org>
AuthorDate: Fri, 17 Apr 2009 09:40:49 +0200
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Fri, 17 Apr 2009 18:00:00 +0200

lockdep: more robust lockdep_map init sequence

Steven Rostedt reported:

> 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.

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.

[ Impact: fix lock tracing after lockdep warnings. ]

Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <1239954049.23397.4156.camel@laptop>
Signed-off-by: Ingo Molnar <mingo@elte.hu>


---
 kernel/lockdep.c |   22 ++++++++++++++--------
 1 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index b0f0118..accb40c 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);
 }

  reply	other threads:[~2009-04-17 16:05 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
2009-04-17 16:03               ` tip-bot for Peter Zijlstra [this message]
2009-04-17  4:16           ` 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=tip-c8a250058656495be02c00de61e26b017c86ef00@git.kernel.org \
    --to=peterz@infradead.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --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