Re: Recursion bug in -rt

[david singleton]

Dinakar,
	can you try patch-2.6.15-rc7-rt3-rf1  on  
http://source.mvista.com/~dsingleton/ and see if it works for your 
tests?

	This new patch creates a 'futex_deadlock' semaphore that we hang 
applications that
are deadlocking themselves.    This method will only hang the 
application, not the system,
as no other locks are held, like the mmap_sem,  just the futex_deadlock 
semaphore.

	NOTE: for pthread_mutexes  that are robust but NOT POSIX priority 
inheriting I return -EWOULDDEADLOCK,
since there is no POSIX specfication for robust pthread_mutexes yet.    
POSIX PI pthread_mutexes will hang
on the futex_deadlock semaphore.

	Let me know how it works.

David




On Dec 20, 2005, at 7:50 AM, Dinakar Guniguntala wrote:

> On Tue, Dec 20, 2005 at 02:19:56PM +0100, Ingo Molnar wrote:
> > hm, i'm looking at -rf4 - these changes look fishy:
> >
> > -       _raw_spin_lock(&lock_owner(lock)->task->pi_lock);
> > +       if (current != lock_owner(lock)->task)
> > +               _raw_spin_lock(&lock_owner(lock)->task->pi_lock);
> >
> > why is this done?
>
> Ingo, this is to prevent a kernel hang due to application error.
>
> Basically when an application does a pthread_mutex_lock twice on a
> _nonrecursive_ mutex with robust/PI attributes the whole system hangs.
> Ofcourse the application clearly should not be doing anything like
> that, but it should not end up hanging the system either
>
> 	-Dinakar

-
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/