>From: Ingo Molnar [mailto:[EMAIL PROTECTED] > >* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote: > >> Let me re-phrase then: it is a must have only on PI, to make sure you >> don't have a loop when doing it. Maybe is a consequence of the >> algorithm I chose. -However- it should be possible to disable it in >> cases where you are reasonably sure it won't happen (such as kernel >> code). In any case, AFAIR, I still did not implement it. > >are there cases where userspace wants to disable deadlock-detection for >its own locks?
I would guess--if I know I have coded my application properly (cough) or I am using locks that by design are completely orthogonal, I would say deadlock checking is getting in the way. >the deadlock detector in PREEMPT_RT is pretty much specialized for >debugging (it does all sorts of weird locking tricks to get the first >deadlock out, and to really report it on the console), but it ought to >be possible to make it usable for userspace-controlled locks as well. fusyn's is as simple as it can get: when you are about to lock(), it checks that you don't own the lock already, but it generalizes it (it checks that the owner of the lock is not waiting for a lock whose owner is waiting for a lock whose owner...is waiting for a lock that you own). -- Inaky - 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/
