linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alexander Viro <viro@ftp.linux.org.uk>,
	"Theodore Ts'o" <tytso@mit.edu>, "H. Peter Anvin" <hpa@zytor.com>
Subject: [PATCH] spinlock/debugging: Print out lock name when available
Date: Fri, 15 Feb 2013 12:39:43 +0100	[thread overview]
Message-ID: <20130215113943.GC26955@gmail.com> (raw)
In-Reply-To: <CA+55aFwpFFg+Z28aZ=92bGdU+Va00j08BzL-2frtLarKWt=qOQ@mail.gmail.com>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, Feb 13, 2013 at 3:10 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > Setting up Logical Volume Management: [   13.140000] BUG: spinlock lockup suspected on CPU#1, lvm.static/139
> > [   13.140000] BUG: spinlock lockup suspected on CPU#1, lvm.static/139
> > [   13.140000]  lock: 0x97fe9fc0, .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1
> 
> Btw, this is an entirely unrelated thing, but it just struck 
> me: you have CONFIG_DEBUG_LOCK_ALLOC in your config, so that 
> spinlock has a _name_, and the not-so-helpful "spin_dump()" is 
> too stupid to even bother to print it out.

Yeah - the spinlock debug code predates lockdep.

> Now, in this case, it doesn't much matter, since the callchain 
> really does end up showing pretty unambiguously what the lock 
> is, but shouldn't we print that lock name when we dump the 
> lock information?
> 
> I dunno. Maybe the names aren't useful, and the callchain ends 
> up always making them redundant. But it seems an oversight in 
> our debug output.

I think it's generally useful, sometimes, for deep crashes we 
don't get a call-chain at all.

Something like the patch below? (entirely untested)

( Using CPP macros to not have to create trivial wrappers for 
  half a dozen lock types. 'dep_map' is not a very likely source 
  of typos and type confusion in any case. )

We could also do a kallsyms lookup like lockdep does - but I'd 
rather keep the spinlock debugging code simple and while 
checking that code I noticed that 
kernel/lockdep.c:print_lockdep_cache() is probably buggy as it 
subtly returns an on-stack variable ... Needs a separate fix.

Thanks,

	Ingo

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index f05631e..17df33a 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -315,6 +315,8 @@ static inline int lockdep_match_key(struct lockdep_map *lock,
 	return lock->key == key;
 }
 
+#define lock_name(lock) ((lock)->dep_map.name)
+
 /*
  * Acquire a lock.
  *
@@ -373,6 +375,8 @@ static inline void lockdep_on(void)
 {
 }
 
+# define lock_name(lock) ""
+
 # define lock_acquire(l, s, t, r, c, n, i)	do { } while (0)
 # define lock_release(l, n, i)			do { } while (0)
 # define lock_set_class(l, n, k, s, i)		do { } while (0)
diff --git a/lib/spinlock_debug.c b/lib/spinlock_debug.c
index 0374a59..80d4818 100644
--- a/lib/spinlock_debug.c
+++ b/lib/spinlock_debug.c
@@ -55,15 +55,19 @@ static void spin_dump(raw_spinlock_t *lock, const char *msg)
 
 	if (lock->owner && lock->owner != SPINLOCK_OWNER_INIT)
 		owner = lock->owner;
-	printk(KERN_EMERG "BUG: spinlock %s on CPU#%d, %s/%d\n",
+
+	printk(KERN_EMERG "BUG: spinlock %s on CPU#%d, %s/%d %s\n",
 		msg, raw_smp_processor_id(),
-		current->comm, task_pid_nr(current));
+		current->comm, task_pid_nr(current),
+		lock_name(lock));
+
 	printk(KERN_EMERG " lock: %pS, .magic: %08x, .owner: %s/%d, "
 			".owner_cpu: %d\n",
 		lock, lock->magic,
 		owner ? owner->comm : "<none>",
 		owner ? task_pid_nr(owner) : -1,
 		lock->owner_cpu);
+
 	dump_stack();
 }
 

      reply	other threads:[~2013-02-15 11:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-08 21:51 Linux v3.8-rc7 Linus Torvalds
2013-02-10  0:14 ` [REGRESSION] -rc7/-rc4+: unable to USB boot - enumeration partially broken (was: Linux v3.8-rc7) Andreas Mohr
2013-02-10 14:05   ` Andreas Mohr
2013-02-12 16:07     ` Andreas Mohr
2013-02-12 16:16       ` Greg KH
2013-02-12 21:25         ` Andreas Mohr
2013-02-13  6:44         ` [REGRESSION] [nailed] USB boot failure: USB: EHCI: make ehci-pci a separate driver Andreas Mohr
2013-02-13  7:16           ` Andreas Mohr
2013-02-13  7:44             ` Andreas Mohr
2013-02-13 10:05               ` Andreas Mohr
2013-02-13 10:50                 ` Colin Guthrie
2013-02-13 16:13                   ` Andreas Mohr
2013-02-13 16:26                     ` Colin Guthrie
2013-02-13 11:10 ` [-rc7 regression] Block IO/VFS/ext3/timer spinlock lockup? Ingo Molnar
2013-02-13 16:59   ` Linus Torvalds
2013-02-13 23:20     ` Thomas Gleixner
2013-02-14 14:45       ` Ingo Molnar
2013-02-14 14:54         ` Ingo Molnar
2013-02-14 15:08           ` Ingo Molnar
2013-02-14 17:28             ` Thomas Gleixner
2013-02-14 18:22             ` Yinghai Lu
2013-02-15 11:44               ` [-rc7 regression] Buggy commit: "mm: use aligned zone start for pfn_to_bitidx calculation" Ingo Molnar
2013-02-15 22:06                 ` Greg KH
2013-02-16  8:29                   ` Ingo Molnar
2013-03-01 16:50                     ` Greg KH
2013-03-01 17:07                       ` Linus Torvalds
2013-03-01 17:14                         ` Greg KH
2013-02-16  8:25                 ` Ingo Molnar
2013-02-16 18:26                 ` Linus Torvalds
2013-02-16 19:38                   ` Yinghai Lu
2013-02-16 19:51                     ` Linus Torvalds
2013-02-18  8:49                   ` Ingo Molnar
2013-02-18 14:46                   ` Mel Gorman
2013-02-18 18:42                     ` Laura Abbott
2013-02-14 23:05   ` [-rc7 regression] Block IO/VFS/ext3/timer spinlock lockup? Linus Torvalds
2013-02-15 11:39     ` Ingo Molnar [this message]

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=20130215113943.GC26955@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=axboe@kernel.dk \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=viro@ftp.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).