timer: Try to survive timer callback preempt_count leak
If a timer callback leaks preempt_count we currently assert a
BUG(). That makes it unnecessarily hard to retrieve information about
the problem especially on laptops and headless stations.
There is a decent chance to survive the preempt_count leak by
restoring the preempt_count to the value before the callback. That
allows in many cases to get valuable information about the root cause
of the problem.
We carried that fixup in preempt-rt for years and were able to decode
such wreckage quite a few times.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Veen <arjan@infradead.org>
diff --git a/kernel/timer.c b/kernel/timer.c
index 4522969..7e12e7b 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -982,9 +982,15 @@
lock_map_release(&lockdep_map);
if (preempt_count != preempt_count()) {
- printk(KERN_ERR "timer: %pF preempt leak: %08x -> %08x\n",
- fn, preempt_count, preempt_count());
- BUG();
+ WARN_ONCE(1, "timer: %pF preempt leak: %08x -> %08x\n",
+ fn, preempt_count, preempt_count());
+ /*
+ * Restore the preempt count. That gives us a decent
+ * chance to survive and extract information. If the
+ * callback kept a lock held, bad luck, but not worse
+ * than the BUG() we had.
+ */
+ preempt_count() = preempt_count;
}
}