summaryrefslogtreecommitdiffstats
path: root/kernel/sched_fair.c
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2008-04-28 09:23:24 +0200
committerThomas Gleixner <tglx@linutronix.de>2008-04-28 22:22:21 +0200
commit0c96c5979a522c3323c30a078a70120e29b5bdbc (patch)
tree1cd5cabe5a3591ce8f22640675921289298d0c40 /kernel/sched_fair.c
parente31a94ed371c70855eb30b77c490d6d85dd4da26 (diff)
downloadop-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
OpenPOWER on IntegriCloud