From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 23 22:12:13 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 C85C816A4CF for ; Thu, 23 Dec 2004 22:12:13 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D37043D3F for ; Thu, 23 Dec 2004 22:12:13 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iBNMC6bU002069; Thu, 23 Dec 2004 17:12:06 -0500 (EST) Date: Thu, 23 Dec 2004 17:12:06 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jan Engelhardt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) 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 Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2004 22:12:13 -0000 On Thu, 23 Dec 2004, Jan Engelhardt wrote: > Hello list, > > > for some reason, the Freebsd (5.3) kernel crashes whenever I do "simple > operations", in conjunction with a (self-written) kernel module. > > I have trimmed the original program down from approx 120 KB to the 7 KB (lots > of spacing and tabs :) to follow the common advise to find the shortest > codepiece showing the problem. > Well, you can retrieve the short prog at http://linux01.org/~jengelh/BUG.tbz2 > Both files (rpldev.c and rpld.c) seem perfectly fine, but ... > see rpld.c for the details of the crash. > > Hope someone can shed some light on this. I don't think you are suppose to leave the kernel with mutex(es) held. A mutex is a short term lock, and at best you are abusing it's intended use. Moreover, I don't think you should leave the kernel with _any_ kernel synchronization object held. In the case of the mutex, the thread performing the close() may not be the thread that did the open() and which owns the mutex. -- DE