timer: Try to survive timer callback preempt_count leak
authorThomas Gleixner <tglx@linutronix.de>
Fri, 12 Mar 2010 19:13:23 +0000 (20:13 +0100)
committerThomas Gleixner <tglx@linutronix.de>
Fri, 12 Mar 2010 21:40:44 +0000 (22:40 +0100)
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>
kernel/timer.c

index 45229694dc6a31e8536c142eac20a407be66fe35..7e12e7bc7ce6dc5f9322f7ddf65917d2f86aed58 100644 (file)
@@ -982,9 +982,15 @@ static void call_timer_fn(struct timer_list *timer, void (*fn)(unsigned long),
        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;
        }
 }