Re: Recursion bug in -rt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


can you try patch-2.6.15-rc7-rt3-rf1 on 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.


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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux