Re: Recursion bug in -rt

From: Dinakar Guniguntala
Date: Mon Dec 19 2005 - 06:38:24 EST


On Fri, Dec 16, 2005 at 01:26:44PM -0800, David Singleton wrote:
> Dinakar,
>
> I believe this patch will give you the behavior you expect.
>
> http://source.mvista.com/~dsingleton/patch-2.6.15-rc5-rt2-rf3

Not really, the reason, quoting from my previous mail

So IMO the above check is not right. However removing this check
is not the end of story. This time it gets to task_blocks_on_lock
and tries to grab the task->pi_lock of the owvner which is itself
and results in a system hang. (Assuming CONFIG_DEBUG_DEADLOCKS
is not set). So it looks like we need to add some check to
prevent this below in case lock_owner happens to be current.

_raw_spin_lock(&lock_owner(lock)->task->pi_lock);

The patch that works for me is attached below

-Dinakar


Index: linux-2.6.14-rt22-rayrt5/kernel/rt.c
===================================================================
--- linux-2.6.14-rt22-rayrt5.orig/kernel/rt.c 2005-12-15 02:15:13.000000000 +0530
+++ linux-2.6.14-rt22-rayrt5/kernel/rt.c 2005-12-19 15:51:26.000000000 +0530
@@ -1042,7 +1042,8 @@
return;
}
#endif
- _raw_spin_lock(&lock_owner(lock)->task->pi_lock);
+ if (current != lock_owner(lock)->task)
+ _raw_spin_lock(&lock_owner(lock)->task->pi_lock);
plist_add(&waiter->pi_list, &lock_owner(lock)->task->pi_waiters);
/*
* Add RT tasks to the head:
@@ -1055,7 +1056,8 @@
*/
if (task->prio < lock_owner(lock)->task->prio)
pi_setprio(lock, lock_owner(lock)->task, task->prio);
- _raw_spin_unlock(&lock_owner(lock)->task->pi_lock);
+ if (current != lock_owner(lock)->task)
+ _raw_spin_unlock(&lock_owner(lock)->task->pi_lock);
}

/*
@@ -3016,8 +3018,7 @@
* the first waiter and we'll just block on the down_interruptible.
*/

- if (owner_task != current)
- down_try_futex(lock, owner_task->thread_info __EIP__);
+ down_try_futex(lock, owner_task->thread_info __EIP__);

/*
* we can now drop the locks because the rt_mutex is held.