LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: tip-bot for Steven Rostedt <rostedt@goodmis.org>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@redhat.com,
	a.p.zijlstra@chello.nl, rostedt@goodmis.org, tglx@linutronix.de,
	mingo@elte.hu
Subject: [tip:core/locking] lockdep/timers: Explain in detail the locking problems del_timer_sync() may cause
Date: Wed, 16 Feb 2011 13:51:04 GMT	[thread overview]
Message-ID: <tip-48228f7b470a74b6469a250d2977a13128d8fe96@git.kernel.org> (raw)
In-Reply-To: <1297186794.23343.19.camel@gandalf.stny.rr.com>

Commit-ID:  48228f7b470a74b6469a250d2977a13128d8fe96
Gitweb:     http://git.kernel.org/tip/48228f7b470a74b6469a250d2977a13128d8fe96
Author:     Steven Rostedt <rostedt@goodmis.org>
AuthorDate: Tue, 8 Feb 2011 12:39:54 -0500
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Wed, 16 Feb 2011 13:35:08 +0100

lockdep/timers: Explain in detail the locking problems del_timer_sync() may cause

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 ticky 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@goodmis.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1297186794.23343.19.camel@gandalf.stny.rr.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/timer.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/kernel/timer.c b/kernel/timer.c
index d645992..5f40c2e 100644
--- a/kernel/timer.c
+++ b/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 *timer)
 #ifdef CONFIG_LOCKDEP
 	unsigned long flags;
 
+	/*
+	 * If lockdep gives a backtrace here, please reference
+	 * the synchronization rules above.
+	 */
 	local_irq_save(flags);
 	lock_map_acquire(&timer->lockdep_map);
 	lock_map_release(&timer->lockdep_map);

  reply	other threads:[~2011-02-16 13:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03  3:19 Regression: WARNINGS and lockdep spews in 2.6.38-rc3+ (bisected) Nick Bowler
2011-02-03  9:12 ` Yong Zhang
2011-02-03  9:30   ` Peter Zijlstra
2011-02-03 10:17     ` Yong Zhang
2011-02-03 10:33       ` Peter Zijlstra
2011-02-03 11:42         ` Yong Zhang
2011-02-08 16:55           ` Peter Zijlstra
2011-02-08 17:39             ` [PATCH] lockdep/timers: Explain in detail the locking problems del_timer_sync() may cause Steven Rostedt
2011-02-16 13:51               ` tip-bot for Steven Rostedt [this message]
2011-02-03 11:50       ` [PATCH 1/2] softirq: introduce loacal_bh_enable_force_wake() Yong Zhang
2011-02-03 11:53       ` [PATCH 2/2] timer: use local_bh_enable_force_wake() in del_timer_sync() Yong Zhang

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=tip-48228f7b470a74b6469a250d2977a13128d8fe96@git.kernel.org \
    --to=rostedt@goodmis.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --subject='Re: [tip:core/locking] lockdep/timers: Explain in detail the locking problems del_timer_sync() may cause' \
    /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

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).