The patch titled
Subject: lib/spinlock_debug.c: prevent an infinite recursive cycle in spin_dump()
has been added to the -mm tree. Its filename is
lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Byungchul Park <byungchul.park@xxxxxxx>
Subject: lib/spinlock_debug.c: prevent an infinite recursive cycle in spin_dump()
There is an infinite recursive cycle when using CONFIG_DEBUG_SPINLOCK, in
spin_dump(). Backtrace prints printk() -> console_trylock() ->
do_raw_spin_lock() -> spin_bug() -> spin_dump() -> printk()...
infinitely.
If the spin_bug() is called from a function like printk() which is trying
to obtain the console lock, we should prevent the debug spinlock code from
calling printk() again in that context.
Signed-off-by: Byungchul Park <byungchul.park@xxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: Akinobu Mita <akinobu.mita@xxxxxxxxx>
Cc: Jan Kara <jack@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
kernel/locking/spinlock_debug.c | 11 +++++++++++
kernel/printk/printk.c | 5 +++++
2 files changed, 16 insertions(+)
diff -puN kernel/locking/spinlock_debug.c~lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump kernel/locking/spinlock_debug.c
--- a/kernel/locking/spinlock_debug.c~lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump
+++ a/kernel/locking/spinlock_debug.c
@@ -67,11 +67,22 @@ static void spin_dump(raw_spinlock_t *lo
dump_stack();
}
+extern int is_console_lock(raw_spinlock_t *lock);
+
static void spin_bug(raw_spinlock_t *lock, const char *msg)
{
if (!debug_locks_off())
return;
+ /*
+ * If this function is called from a function like printk()
+ * which is trying to obtain the console lock, then we should
+ * not call printk() any more. Or it will cause an infinite
+ * recursive cycle!
+ */
+ if (unlikely(is_console_lock(lock)))
+ return;
+
spin_dump(lock, msg);
}
diff -puN kernel/printk/printk.c~lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump kernel/printk/printk.c
--- a/kernel/printk/printk.c~lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump
+++ a/kernel/printk/printk.c
@@ -120,6 +120,11 @@ static int __down_trylock_console_sem(un
up(&console_sem);\
} while (0)
+int is_console_lock(raw_spinlock_t *lock)
+{
+ return &console_sem.lock == lock;
+}
+
/*
* This is used for debugging the mess that is the VT code by
* keeping track if we have the console semaphore held. It's
_
Patches currently in -mm which might be from byungchul.park@xxxxxxx are
lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
