From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: Lucio De Re Date: Thu, 18 Nov 2010 20:23:28 +0200 In-Reply-To: <3b7a16b6d7ba18893953f5b1c9978f05@vitanuova.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] That deadlock, again Topicbox-Message-UUID: 853060e2-ead6-11e9-9d60-3106f5b1d025 > it's to allow the use during reset of a given driver's > standard functions that normally must qlock, to avoid requiring two copies > of them, with and without the qlock. > > after reset, it's illegal to call qlock without a process (notably > in an interrupt function), as it previously was. I'm willing to credit the validity of this, but I believe then that it ought to be more explicit. It seems to me that having a situation where a panic can ensue if a lock is already taken is too risky. Is it possible to count the instances of such qlock() invocations in the present kernel code and find out how common the problem really is? Or should one simply treat such invocations as innocuous and just omit connecting a user process to the queue when no user process is specified, if the lock is taken? That sounds positively explosive! ++L