Date: Wed, 5 Sep 2007 13:57:03 -0500 (CDT) From: Russell Cattelan <cattelan@thebarn.com> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/116133: Recursive lock panic when w_mtx falls into DELAY Message-ID: <200709051857.l85Iv3J5066532@mist.panasas.com> Resent-Message-ID: <200709051940.l85Je44t000618@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709051857.l85Iv3J5066532>