[PATCH 2/7] fix posix-timers signals lock order

[Roland McGrath]

Note that releasing the siglock here adds new instances of existing job
control races in the 2.6.10 code.  This issue goes away if you use my
stoprace-fix patch (already in 2.6.10-rc3-mm1).  So it is advised to apply
those signal fixes before using this patch.

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@xxxxxxxxxx>

--- linux-2.6/kernel/signal.c 17 Nov 2004 23:13:14 -0000
+++ linux-2.6/kernel/signal.c 17 Nov 2004 23:14:48 -0000
@@ -564,7 +564,15 @@
 	if ( signr &&
 	     ((info->si_code & __SI_MASK) == __SI_TIMER) &&
 	     info->si_sys_private){
- 		do_schedule_next_timer(info);
+		/*
+		 * 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;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/