From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 11 21:27:24 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 BBC2916A4CE for ; Mon, 11 Oct 2004 21:27:24 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9354043D3F for ; Mon, 11 Oct 2004 21:27:24 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 19815 invoked from network); 11 Oct 2004 21:27:21 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Oct 2004 21:27:21 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i9BLRH6O042482; Mon, 11 Oct 2004 17:27:17 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Mon, 11 Oct 2004 14:55:16 -0400 User-Agent: KMail/1.6.2 References: <1097500245.416a86556c692@imp1-q.free.fr> <20041011173042.B744@curly.tele2.no> In-Reply-To: <20041011173042.B744@curly.tele2.no> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410111455.16920.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: damien.bergamini@free.fr cc: Hans Petter Selasky Subject: Re: msleep(9) and recursed mutex 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: Mon, 11 Oct 2004 21:27:24 -0000 On Monday 11 October 2004 11:30 am, Hans Petter Selasky wrote: > On Mon, Oct 11, 2004 at 03:10:45PM +0200, damien.bergamini@free.fr wrote: > > msleep(9) behaves strangely with recursed mutexes. > > In the attached code, calling foo_f() will make the kernel hang for > > two seconds. > > It seems like msleep does not release the mtx mutex completely but > > simply decrement its reference count by one. When calling msleep, the > > mtx mutex is still held which prevent the interrupt from happening. > > msleep will then return error code EWOULDBLOCK after two seconds. > > If I remove calls to mtx_lock/unlock from function foo_g(), it works > > without problem but this is not a solution since foo_g() can be > > called outside of function foo_f(). > > Of course, the mtx mutex was created with the MTX_RECURSE flag set. > > > > Is it an expected behaviour? In msleep(9) it is said: > > "The msleep() function is a variation on tsleep. The parameter mtx > > is a mutex which will be released before sleeping and reacquired > > before msleep() returns." > > > > Seems like the mutex is not *really* released if it recurses. > > Only the "Giant" mutex is released if it recurses. By the way there is > a bug in msleep: > > mtx_lock(&Giant); > msleep(xxx, &Giant, 0, "foo", 0); > mtx_unlock(&Giant); This is a bug. Giant is a special mutex that should not be used in properly locked code. That is, if you are using msleep() or condition variables you should be using it with your own mutexes rather than Giant. We can add some assertions to ensure that Giant is not passed in and that recursive mutexes are not used though. Actually, we already assert that the mutex is not recursed. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org