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();
}
prev parent 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).