The patch titled
lockdep/timers: explain in detail the locking problems del_timer_sync() may cause
has been added to the -mm tree. Its filename is
lockdep-timers-explain-in-detail-the-locking-problems-del_timer_sync-may-cause.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 ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: lockdep/timers: explain in detail the locking problems del_timer_sync() may cause
From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Twice I had to explain the output about why lockdep gives an error with
locks in IRQ context and with del_timer_sync(). Might as well write it up
and place it in the comments above the code in del_timer_sync(). Perhaps
the next time this lockdep dump triggers people will understand the
issues.
It is a tricky issue and very subtle, explaining it in detail in the code
may help others understand the issue when they stumble upon the bug again.
Signed-off-by: Steven Rostedt <rostedt@xxxxxxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: Yong Zhang <yong.zhang0@xxxxxxxxx>
Cc: Nick Bowler <nbowler@xxxxxxxxxxxxxxxx>
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
kernel/timer.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff -puN kernel/timer.c~lockdep-timers-explain-in-detail-the-locking-problems-del_timer_sync-may-cause kernel/timer.c
--- a/kernel/timer.c~lockdep-timers-explain-in-detail-the-locking-problems-del_timer_sync-may-cause
+++ a/kernel/timer.c
@@ -964,6 +964,25 @@ EXPORT_SYMBOL(try_to_del_timer_sync);
* add_timer_on(). Upon exit the timer is not queued and the handler is
* not running on any CPU.
*
+ * Note: You must not hold locks that are held in interrupt context
+ * while calling this function. Even if the lock has nothing to do
+ * with the timer in question. Here's why:
+ *
+ * CPU0 CPU1
+ * ---- ----
+ * <SOFTIRQ>
+ * call_timer_fn();
+ * base->running_timer = mytimer;
+ * spin_lock_irq(somelock);
+ * <IRQ>
+ * spin_lock(somelock);
+ * del_timer_sync(mytimer);
+ * while (base->running_timer == mytimer);
+ *
+ * Now del_timer_sync() will never return and never release somelock.
+ * The interrupt on the other CPU is waiting to grab somelock but
+ * it has interrupted the softirq that CPU0 is waiting to finish.
+ *
* The function returns whether it has deactivated a pending timer or not.
*/
int del_timer_sync(struct timer_list *timer)
@@ -971,6 +990,10 @@ int del_timer_sync(struct timer_list *ti
#ifdef CONFIG_LOCKDEP
unsigned long flags;
+ /*
+ * If lockdep gives a backtrace here, please reference
+ * the synchronization rules above.
+ */
raw_local_irq_save(flags);
local_bh_disable();
lock_map_acquire(&timer->lockdep_map);
_
Patches currently in -mm which might be from rostedt@xxxxxxxxxxx are
linux-next.patch
lockdep-timers-explain-in-detail-the-locking-problems-del_timer_sync-may-cause.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
