aboutsummaryrefslogtreecommitdiff
path: root/usr
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2008-04-29 01:15:10 +0000
committerGreg Kroah-Hartman <gregkh@suse.de>2008-05-01 14:44:39 -0700
commitf5f5e084959d9c22c43c235b206b2e2fe2971e7f (patch)
tree761b3106f0c116b37d38b72d6b9c47cba7930396 /usr
parentfa455bcd0a6460ef6543ebb212940fedf9f3170f (diff)
hrtimer: raise softirq unlocked to avoid circular lock dependency
commit 0c96c5979a522c3323c30a078a70120e29b5bdbc upstream 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> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'usr')
0 files changed, 0 insertions, 0 deletions