Re: 2.6.13-rt1

[Steven Rostedt <rostedt@goodmis.org>]

Ingo,

I just found another deadlock in the pi_lock logic.  The PI logic is
very dependent on the P1->L1->P2->L2->P3 order.  But our good old friend
is back, the BKL.

Since the BKL is let go and regrabbed even if a task is grabbing another
lock, it messes up the order.  For example, it can do the following:
L1->P1->L2->P2->L1 if L1 is the BKL.  Luckly, (and I guess there's
really no other way) the BKL is only held by those that are currently
running, or at least not blocked on anyone.  So I added code in the
pi_setprio code to test if the next lock in the loop is the BKL and if
so, if its owner is the current task.  If so, the loop is broken.

Without this patch, I would constantly get lock ups on shutdown where it
sends SIGTERM to all the processes.  It usually would lock up on the
killing of udev.  But with the patch, I've shutdown a few times already
and no lockups so far.

-- Steve

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Index: linux_realtime_goliath/kernel/rt.c
===================================================================
--- linux_realtime_goliath/kernel/rt.c	(revision 308)
+++ linux_realtime_goliath/kernel/rt.c	(working copy)
@@ -816,6 +816,21 @@
 		l = w->lock;
 		TRACE_BUG_ON_LOCKED(!lock);
 
+		/*
+		 * The BKL can really be a pain.  It can happen that the lock
+		 * we are blocked on is owned by a task that is waiting for
+		 * the BKL, and we own it.  So, if this is the BKL and we own
+		 * it, then end the loop here.
+		 */
+		if (unlikely(l == &kernel_sem.lock) && lock_owner(l) == current_thread_info()) {
+			/*
+			 * No locks are held for locks, so fool the unlocking code
+			 * by thinking the last lock was the original.
+			 */
+			l = lock;
+			break;
+		}
+
 		if (l != lock)
 			__raw_spin_lock(&l->wait_lock);