hrtimer: raise softirq unlocked to avoid circular lock dependency
authorThomas Gleixner <tglx@linutronix.de>
Mon, 28 Apr 2008 07:23:24 +0000 (09:23 +0200)
committerThomas Gleixner <tglx@linutronix.de>
Mon, 28 Apr 2008 20:22:21 +0000 (22:22 +0200)
commit0c96c5979a522c3323c30a078a70120e29b5bdbc
tree1cd5cabe5a3591ce8f22640675921289298d0c40
parente31a94ed371c70855eb30b77c490d6d85dd4da26
hrtimer: raise softirq unlocked to avoid circular lock dependency

The scheduler hrtimer bits in 2.6.25 introduced a circular lock
dependency in a rare code path:

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.25-sched-devel.git-x86-latest.git #19
-------------------------------------------------------
X/2980 is trying to acquire lock:
 (&rq->rq_lock_key#2){++..}, at: [<ffffffff80230146>] task_rq_lock+0x56/0xa0

but task is already holding lock:
 (&cpu_base->lock){++..}, at: [<ffffffff80257ae1>] lock_hrtimer_base+0x31/0x60

which lock already depends on the new lock.

The scenario which leads to this is:

posix-timer signal is delivered
 -> posix-timer is rearmed
    timer is already expired in hrtimer_enqueue()
     -> softirq is raised

To prevent this we need to move the raise of the softirq out of the
base->lock protected code path.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@kernel.org
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
kernel/hrtimer.c