diff options
author | Thomas Gleixner <tglx@linutronix.de> | 2008-04-28 09:23:24 +0200 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2008-04-28 22:22:21 +0200 |
commit | 0c96c5979a522c3323c30a078a70120e29b5bdbc (patch) | |
tree | 1cd5cabe5a3591ce8f22640675921289298d0c40 /kernel/sched_fair.c | |
parent | e31a94ed371c70855eb30b77c490d6d85dd4da26 (diff) | |
download | op-kernel-dev-0c96c5979a522c3323c30a078a70120e29b5bdbc.zip op-kernel-dev-0c96c5979a522c3323c30a078a70120e29b5bdbc.tar.gz |
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>
Diffstat (limited to 'kernel/sched_fair.c')
0 files changed, 0 insertions, 0 deletions