linux-kernel - Re: [PATCH 2/2] tracing/events/lockdep: move tracepoints within recursive protection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1239954049.23397.4156.camel@laptop>
Date:	Fri, 17 Apr 2009 09:40:49 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 2/2] tracing/events/lockdep: move tracepoints within
 recursive protection

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@...llo.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);
 }


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