From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 19:28:23 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 C96EB10657DC for ; Mon, 12 Jan 2009 19:28:23 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA028FC2D for ; Mon, 12 Jan 2009 19:28:22 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3778312fgb.35 for ; Mon, 12 Jan 2009 11:28:22 -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=L5bNbVX4QsjOYSa7UPlMHxdqOiiwDrhVWrE8rNVIv2A=; b=mgeTzEzw7hh/aq730y64HI3M4V4ODrObQAkQLmk45+8HyZHOXV6lwJD08uRVm6quJV ZH8SWBw4L72YdwY1Re10YhBPn2xBrU4jZooXFBGJlXFkorl1Flq8QXXxYAgbeshdDM+n DZu/7VCH60KuNM/MYqB3lnvIfKIZ2dVBO5Ltk= 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=ZROZp+o6I1GlZ0ucFQr952JvoakXvMetafoK8dxFroKjnLJPApHmWIcyycXfdy3C8I 4lXkFPFh7npO97U1Ur36ISnDYLN6XtzymUNTT0fPnmC0Zm5g+AZBNB32FphZQ1DDe0ZS bR/mXk16SpCcN2ZZ1O4nGQgyYm6UVszm1KCzE= Received: by 10.86.76.16 with SMTP id y16mr17033757fga.65.1231788502201; Mon, 12 Jan 2009 11:28:22 -0800 (PST) Received: from gmail.com (sdferwer192.net.autocom.pl [77.236.1.49]) by mx.google.com with ESMTPS id d4sm7871468fga.31.2009.01.12.11.28.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Jan 2009 11:28:21 -0800 (PST) Date: Mon, 12 Jan 2009 20:28:22 +0100 From: Mateusz Guzik To: Alexej Sokolov Message-ID: <20090112192822.GB2102@skucha> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <671bb5fc0901121016m7932666cpfe3c089d4c78486e@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 19:28:24 -0000 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