From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 2 18:20:40 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 E4F8210656EA for ; Mon, 2 Feb 2009 18:20:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outs.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id C4C708FC0A for ; Mon, 2 Feb 2009 18:20:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 3DD1824B6; Mon, 2 Feb 2009 10:09:04 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4CCFF2D6021; Mon, 2 Feb 2009 10:09:03 -0800 (PST) Message-ID: <498736C2.3040207@elischer.org> Date: Mon, 02 Feb 2009 10:09:06 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: John Baldwin References: <02026848-7F83-405C-B4F3-EDD8B47DA294@gmail.com> <32679C0A-28C1-4D7A-950C-580787F3971D@gmail.com> <200902020845.21773.jhb@freebsd.org> In-Reply-To: <200902020845.21773.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, =?UTF-8?B?Tmlrb2xhIEtuZcW+ZXZpxIc=?= Subject: Re: blockable sleep lock (sleep mutex) 16 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, 02 Feb 2009 18:20:42 -0000 John Baldwin wrote: > On Monday 02 February 2009 7:33:08 am Nikola Knežević wrote: >> On 30 Jan 2009, at 18:11 , Nikola Knežević wrote: >> >>> This is the message buffer: >>> Unread portion of the kernel message buffer: >>> panic: blockable sleep lock (sleep mutex) 16 @ /usr/src/sys/vm/ >>> uma_core.c:1834 >>> Any hints where I should search for the cause? >> >> Ok, I solved this problem. I had a critical_enter/exit surrounding >> code which was calling a lot of mallocs. Now, I'm getting another >> message, which doesn't make any sense: >> >> ---8<--- >> --- trap 0, rip = 0, rsp = 0xffffffff87834d30, rbp = 0 --- >> uma_zalloc_arg: zone "256" with the following non-sleepable locks held: >> exclusive sleep mutex click_instance r = 0 (0xffffff00051b4540) locked >> @ sched.cc:441 >> --->8--- >> >> It says "non-sleepable locks", yet it classifies click_instance as >> sleep mutex. I think witness code should emit messages which are more >> clear. > > It is confusing, but you can't do an M_WAITOK malloc while holding a mutex. > Basically, sleeping actually means calling "*sleep() (such as mtx_sleep()) or > cv_*wait*()". Blocking on a mutex is not sleeping, it's "blocking". Some > locks (such as sx(9)) do "sleep" when you contest them. In the scheduler, > sleeping and blocking are actually quite different (blocking uses turnstiles > that handle priority inversions via priority propagation, sleeping uses sleep > queues which do not do any of that). The underyling idea is that mutexes > should be held for "short" periods of time, and that any sleeps are > potentially unbounded. Holding a mutex while sleeping could result in a > mutex being held for a long time. > the locking overview page man 9 locking tries to explain this.. I've been pestering John to proofread it and make suggestiosn for a while now. (nag nag)