From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 24 06:28:58 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC53116A4CE for ; Fri, 24 Dec 2004 06:28:58 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52A5D43D46 for ; Fri, 24 Dec 2004 06:28:58 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.13.1) with ESMTP id iBO6TRqO039069; Fri, 24 Dec 2004 01:29:27 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.13.1/Submit) id iBO6TR00039068; Fri, 24 Dec 2004 01:29:27 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Fri, 24 Dec 2004 01:29:27 -0500 From: David Schultz To: Jan Engelhardt Message-ID: <20041224062927.GA38944@VARK.MIT.EDU> Mail-Followup-To: Jan Engelhardt , Max Laier , freebsd-hackers@freebsd.org References: <200412232307.41735.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: Max Laier cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel crash w/o reason X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2004 06:28:58 -0000 On Fri, Dec 24, 2004, Jan Engelhardt wrote: > >1) In kmi_fops.d_open(): > >| if(!mtx_trylock(&Open_lock)) { return EBUSY; } > >| return 0; > > > >this can not work. You cannot return to userland with a lock acquired. > > So? The full code also contains a uio_read() function. If I release the > lock in uio_read(), no crash happens. It's just in uio_close(). > > Why can't I hold this lock, as it is possible with Linux? A mutex is basically > just an atomic counter AFAIK, and if nobody releases it in-between, it is > still held by the time we enter uio_close() - thus it could be unlocked > without problems. In theory at least. This is not allowed because it can lead to deadlock and other unsavory situations. Suppose the user process enters an infinite loop or is waiting for some condition. Now all kernel threads that attempts to acquire the lock will block. And if any of those threads have anything to do with the VM system or scheduler or process exit, then you're really screwed because you won't be able to kill the process. Although Linux does not explicitly enforce this correctness condition, it's still wrong to violate it. > What should I use instead? A semaphore? You shouldn't have unrelated kernel threads waiting for a user process at all, so this sounds like a design problem, regardless of which mutual exclusion primitive you use. (Bear in mind that I haven't actually looked into what you're trying to do.) In any case, you can always use mutexes to implement whatever other synchronization mechanism you need.