On Tue, 2005-08-30 at 11:00 -0400, Steven Rostedt wrote:
> OK, I'm looking for a second set of eyes (or third or more :-) to see if
> there's a danger of a deadlock here.
Unless someone sees a problem with the patch, here it is. I noticed
that I unlocked the lock->wait_lock when I should not have. (scares me
since I'm currently running the kernel with that bug!)
Ingo, in the pi_setprio, I can stop the loop if the owner of the BKL
has a task lock_depth >= 0 correct? This means that the owner is either
running, or is going to go to sleep. If it was blocked on another task,
via a mutex, then this count would be -1. Correct? I may need to move
the setting of lock_depth = -1 to inside the protection of the task
pi_lock.
-- Steve
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux_realtime_goliath/kernel/rt.c
===================================================================
--- linux_realtime_goliath/kernel/rt.c (revision 310)
+++ linux_realtime_goliath/kernel/rt.c (working copy)
@@ -1089,11 +1089,21 @@
__raw_spin_unlock(&new_owner->task->pi_lock);
goto try_again;
}
+ /*
+ * Once again the BKL comes to play. Since the BKL can be grabbed and
released
+ * out of the normal P1->L1->P2 order, there's a chance that someone
has the
+ * BKL owner's lock and is waiting on the new owner lock.
+ */
+ if (unlikely(lock == &kernel_sem.lock)) {
+ if (!__raw_spin_trylock(&old_owner->task->pi_lock)) {
+ __raw_spin_unlock(&new_owner->task->pi_lock);
+ goto try_again;
+ }
+ } else
#endif
+ __raw_spin_lock(&old_owner->task->pi_lock);
+
plist_del_init(&waiter->list, &lock->wait_list);
-
- __raw_spin_lock(&old_owner->task->pi_lock);
-
plist_del(&waiter->pi_list, &old_owner->task->pi_waiters);
plist_init(&waiter->pi_list, waiter->ti->task->prio);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
