From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 20:21:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 375DD1065742 for ; Mon, 12 Jan 2009 20:21:54 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 9C6898FC22 for ; Mon, 12 Jan 2009 20:21:53 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3791635fgb.35 for ; Mon, 12 Jan 2009 12:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=HRdgKe5sCf21eK4G1xdWvnHRNZEEWJTYjbFEu28ozX0=; b=jVwkyDMsfPOLQjg59Vyuz0CMYYdmlj4vURF4lqrpEfjEzQGVxfd+9+Hl0m3MfzueOa DZ59i5wJ62WDiwSfgwRw6/98c/u1PN0WxVUAXh7sNnvkQlfAM7ujSQ/qRyKbshGax/D7 iq0p78LY3gwcZMnAbiEVO9CdZLBKG5wzw8GO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BAy5bydNusrP2Hdt3Dk8NLnDxVfHMgY3Rpyr97pGwN2VI1bK3Y8AUG/cERGRAtJt6h kytTqaYJeG74bYujafxdA2QcS9FmvqsxlPvsLySxuxvbRwo50OPL7Mc7c0NGDwTVIjaL Sga4Vwh+SxMVLMU4VhhAaFSoCJ4l7881/beAU= Received: by 10.86.4.14 with SMTP id 14mr17078534fgd.76.1231791712588; Mon, 12 Jan 2009 12:21:52 -0800 (PST) Received: from gmail.com (sdferwer192.net.autocom.pl [77.236.1.49]) by mx.google.com with ESMTPS id d4sm28165477fga.41.2009.01.12.12.21.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Jan 2009 12:21:52 -0800 (PST) Date: Mon, 12 Jan 2009 21:21:53 +0100 From: Mateusz Guzik To: Alexej Sokolov Message-ID: <20090112202152.GC2102@skucha> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> <20090112192822.GB2102@skucha> <671bb5fc0901121149m71336fd4k9cfe4b18d41df771@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <671bb5fc0901121149m71336fd4k9cfe4b18d41df771@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org Subject: Re: panic by unlocking of mutex in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 20:22:09 -0000 On Mon, Jan 12, 2009 at 08:49:59PM +0100, Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik > > > On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: > > > 2009/1/12 Mateusz Guzik > > > > > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > > > > 2009/1/12 Mateusz Guzik > > > > > > Mutexes have owners. It panics on loading because processes cannot > > > > > > return to userland with locks held. > > > > > > > > > > i am not sure about it. Some time ago i implemented a charecter > > device > > > > with > > > > > two syscalls: write, read. "write" lock the mutex and "read" unlock > > it. > > > > The > > > > > user space programm opens device, then mekes "write" (mutex will held > > in > > > > > kernel), goes back to user space, then makes "read" (mutex will > > unlocked > > > > in > > > > > kernel) and it all run without panic. If needed i can post the source > > > > code. > > > > > > > > > > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > > > > kernel panicked like this (while loading your module): > > > > > > > > System call kldload returning with 1 locks held > > > > > > My kernel is compiled without WITNESS. And it allows to lock mutex in one > > > systcall (for example "write") and to unlock it in other ("read"). > > > Do you mean it is "very bad idea" to do something like this ? > > > I could not find anywhere in the documentation that a it is not allowed > > to > > > return in the user space with a locked mutex. > > > Can you give me some reference on man page, source code or something > > other > > > from where can I understand it ? > > > > > > > Locks are used to synchronize access to data changeable by other > > threads. I don't know if I'm correct here, but let's consider the > > following situation: your process grabs a mutex and returns to userland, > > then it's killed due to segmentation violation. This mutex should (and > > can be) unlocked on exit, but the state of data protected by it is > > unknown. (For example your process was killed while inserting something > > into linked list.) So even if the kernel could be guided to unlock it on > > exit, the data could be in inconsistent state. > > > > Also your locking scheme doesn't make much sense. Consider this: > > proc1 calls write on your cdev > > but in the meantime > > proc2 calls read on your cdev > > > > So you get panic because proc1 was writing some data. (attempt to unlock > > mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would > > read inconsistend data because proc1 was writing. Proper solution is to > > lock mutex before and after reading/writing data. For working example > > you can check how devctl was implemented (sys/kern/subr_bus.c). > > > > -- > > Mateusz Guzik > > > > Ok , now I understaand it. > If a thread return to user space with locked mutex, kernel doesen't know if > the thread will come back to unlock it. It is really unsafe return to > userspace without unlocking of helding mutexes. > Provided example is really unfortunate. :/ Forget it. (And a proper solution for your locking issue is of course to lock mutex before read/write and *unlock* it after it's done. (missed that word in my previous mail)) Threads in userland holding kernel locks would lead to panics in a lot of situations. For example you already have sleepable mutex and call some kernel function that acquires sx lock - the kernel panics as this is not allowed combination. -- Mateusz Guzik