From owner-freebsd-bugs@FreeBSD.ORG Wed Sep 5 19:40:05 2007 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2567F16A473 for ; Wed, 5 Sep 2007 19:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DEAE913C4A6 for ; Wed, 5 Sep 2007 19:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l85Je48M000619 for ; Wed, 5 Sep 2007 19:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l85Je44t000618; Wed, 5 Sep 2007 19:40:04 GMT (envelope-from gnats) Resent-Date: Wed, 5 Sep 2007 19:40:04 GMT Resent-Message-Id: <200709051940.l85Je44t000618@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Russell Cattelan Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE49A16A417 for ; Wed, 5 Sep 2007 19:37:53 +0000 (UTC) (envelope-from cattelan@mist.panasas.com) Received: from mist.panasas.com (ip65-44-182-162.z182-44-65.customer.algx.net [65.44.182.162]) by mx1.freebsd.org (Postfix) with ESMTP id 695FA13C4A8 for ; Wed, 5 Sep 2007 19:37:53 +0000 (UTC) (envelope-from cattelan@mist.panasas.com) Received: from mist.panasas.com (localhost [127.0.0.1]) by mist.panasas.com (8.13.8/8.13.8) with ESMTP id l85Iv3wJ066533 for ; Wed, 5 Sep 2007 13:57:03 -0500 (CDT) (envelope-from cattelan@mist.panasas.com) Received: (from cattelan@localhost) by mist.panasas.com (8.13.8/8.13.8/Submit) id l85Iv3J5066532; Wed, 5 Sep 2007 13:57:03 -0500 (CDT) (envelope-from cattelan) Message-Id: <200709051857.l85Iv3J5066532@mist.panasas.com> Date: Wed, 5 Sep 2007 13:57:03 -0500 (CDT) From: Russell Cattelan To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: kern/116133: Recursive lock panic when w_mtx falls into DELAY X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russell Cattelan List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 19:40:05 -0000 >Number: 116133 >Category: kern >Synopsis: Recursive lock panic when w_mtx falls into DELAY >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 05 19:40:01 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Russell Cattelan >Release: FreeBSD 6.2-STABLE amd64 >Organization: >Environment: System: FreeBSD mist 6.2-STABLE FreeBSD 6.2-STABLE #0: Mon Mar 26 14:29:16 CDT 2007 cattelan@mist:/usrX/src6/sys/amd64/compile/MIST amd64 >Description: Set the MTX_NOWITNESS flag on the clock_lock. Since witness uses mtx_spin_lock internally, any delay on getting the w_mtx lock would cause mtx_spin_lock to fall into the "adaptive" mode and call DELAY internally. DELAY grabs the clock_lock which is also will try to grab the w_mtx mutex trying to insert the clock_lock into the witness data structures. The end result is a recurse lock panic. >How-To-Repeat: >Fix: Index: tango-client/src/freebsd6/src/sys/amd64/amd64/machdep.c =================================================================== --- tango-client.orig/src/freebsd6/src/sys/amd64/amd64/machdep.c 2007-09-04 16:17:53.318140386 -0500 +++ tango-client/src/freebsd6/src/sys/amd64/amd64/machdep.c 2007-09-05 13:29:55.980183838 -0500 @@ -1211,9 +1211,14 @@ hammer_time(u_int64_t modulep, u_int64_t * section, to set pcpu->ipending (etc...) properly, we * must be able to get the icu lock, so it can't be * under witness. + * clock_lock: the adaptive nature of the mutex_spin lock could + * cause obtaining the w_mtx lock to fall into DELAY + * which would then cause a recursive lock panic when + * grabbing the clock_lock and subsequently the w_mtx + * as part of the mtx_lock_spin(clock_lock) call. */ mutex_init(); - mtx_init(&clock_lock, "clk", NULL, MTX_SPIN); + mtx_init(&clock_lock, "clk", NULL, MTX_SPIN | MTX_NOWITNESS); mtx_init(&icu_lock, "icu", NULL, MTX_SPIN | MTX_NOWITNESS); /* exceptions */ Index: tango-client/src/freebsd6/src/sys/i386/i386/machdep.c =================================================================== --- tango-client.orig/src/freebsd6/src/sys/i386/i386/machdep.c 2007-09-03 16:21:05.000000000 -0500 +++ tango-client/src/freebsd6/src/sys/i386/i386/machdep.c 2007-09-05 13:29:40.490965402 -0500 @@ -2135,9 +2135,14 @@ init386(first) * section, to set pcpu->ipending (etc...) properly, we * must be able to get the icu lock, so it can't be * under witness. + * clock_lock: the adaptive nature of the mutex_spin lock could + * cause obtaining the w_mtx lock to fall into DELAY + * which would then cause a recursive lock panic when + * grabbing the clock_lock and subsequently the w_mtx + * as part of the mtx_lock_spin(clock_lock) call. */ mutex_init(); - mtx_init(&clock_lock, "clk", NULL, MTX_SPIN); + mtx_init(&clock_lock, "clk", NULL, MTX_SPIN | MTX_NOWITNESS); mtx_init(&icu_lock, "icu", NULL, MTX_SPIN | MTX_NOWITNESS); /* make ldt memory segments */ >Release-Note: >Audit-Trail: >Unformatted: