From: Roland McGrath <roland@redhat.com>
The posix-timers code establishes the locking order that k_itimer locks are
outside siglocks. However, when the signal code calls back into the
posix-timers code to reload a timer after its signal is dequeued, it holds a
siglock while calling do_schedule_next_timer, which gets a timer lock.
I'm not sure there is any deadlock scenario possible using the real-time POSIX
timers, because of the intricate arrangement of timer firing and resetting
synchronization. But with the new CPU timers code, this deadlock pops up
right away. Dropping the siglock here certainly doesn't hurt in the real-time
timer cases, and it really seems like the right thing here to keep the locking
details in the interface between signals and posix-timers code comprehensible.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
25-akpm/kernel/signal.c | 8 ++++++++
1 files changed, 8 insertions(+)
diff -puN kernel/signal.c~posix-timers-fix-posix-timers-signals-lock-order kernel/signal.c
--- 25/kernel/signal.c~posix-timers-fix-posix-timers-signals-lock-order 2005-01-23 19:05:14.127731720 -0800
+++ 25-akpm/kernel/signal.c 2005-01-23 19:05:14.134730656 -0800
@@ -565,7 +565,15 @@ int dequeue_signal(struct task_struct *t
if ( signr &&
((info->si_code & __SI_MASK) == __SI_TIMER) &&
info->si_sys_private){
+ /*
+ * Release the siglock to ensure proper locking order
+ * of timer locks outside of siglocks. Note, we leave
+ * irqs disabled here, since the posix-timers code is
+ * about to disable them again anyway.
+ */
+ spin_unlock(&tsk->sighand->siglock);
do_schedule_next_timer(info);
+ spin_lock(&tsk->sighand->siglock);
}
return signr;
}
_