Date: Mon, 11 Apr 2005 10:57:37 +0200
From: Ingo Molnar <mingo@elte.hu>
To: "Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>
Cc: Sven-Thorsten Dietrich <sdietrich@mvista.com>,
       Daniel Walker <dwalker@mvista.com>, linux-kernel@vger.kernel.org,
       Steven Rostedt <rostedt@goodmis.org>, Esben Nielsen <simlo@phys.au.dk>,
       Joe Korty <joe.korty@ccur.com>
Subject: Re: [PATCH] Priority Lists for the RT mutex
Message-ID: <20050411085737.GA11109@elte.hu>
References: <F989B1573A3A644BAB3920FBECA4D25A02F64C65@orsmsx407>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F989B1573A3A644BAB3920FBECA4D25A02F64C65@orsmsx407>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1028
Lines: 23


* Perez-Gonzalez, Inaky <inaky.perez-gonzalez@intel.com> 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?

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.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/